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I.  INTRODUCTION 


The  existing  Internet  Protoeol  version  4  (IPv4)  was  developed  in  the  1970’s  and  it 
provides  the  basis  for  today’s  Internet  interoperability.  [Offiee  of  ASD,  2005]  Internet 
Protoeol  version  6  (IPv6)  will  be  the  new  Internet.  It  is  seheduled  to  replaee  the  existing 
Internet  Protocol  version  4.  The  Internet  Engineering  Task  Force  (IETF)  defined  IPv6  in 
Request  For  Comment  (RFC)  1883,  which  was  made  obsolete  by  RFC  2460. 

The  new  protocol  will  facilitate  a  major  improvement  of  features  which  includes 
communications  security,  mobility,  and  the  enabling  of  major  networks  of  sensors  and 
smart  tracking  tags  for  integrated,  enterprise-centric  Government  operations.  [Geesey, 
2006] 

The  article  by  Harrison  [Harrison  et  ah,  2005]  identifies  the  notable 
improvements  in  IPv6  that  include  extended  address  space  (32  bits  in  IPv4  to  128  bits  in 
IPv6),  extended  routing  capabilities,  simpler  and  more  secure  mobile  applications, 
improved  security  via  authentication  and  privacy  features,  auto  configuration,  and 
increased  quality  of  service  (QoS)  capabilities. 

Internet  Protocol  provides  the  critical  functionality  that  enables  stable,  secure 
communications  between  computers  across  various  network  types,  including  local  area 
and  wide  area  networks.  In  order  to  assure  an  effective  and  secure  transition  to  this  new 
protocol,  the  Office  of  Management  and  Budget  (0MB)  issued  guidance  to  the  Chief 
Information  Officers  (CIOs)  of  all  federal  agencies  on  what  actions  should  be  taken  to 
support  this  initiative.  [0MB,  2005] 

A,  PURPOSE  OF  STUDY 

The  purpose  of  this  research  is  to  determine  the  ramifications  of  transitioning  to 
IPv6  in  light  of  the  Governmental  mandated  transition,  particularly  the  transition  of  DoD. 
The  purpose  of  this  thesis  is  to  provide  evidence  of  benefits,  complexity,  and  risks  that 
organizations  may  encounter  while  transitioning  to  IPv6.  It  will  compare  the  Transition 
Plan  to  the  current  state  of  preparedness  by  a  sample  of  DoD  agencies  and  determine  if 
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IPv6  can  be  implemented  by  2008.  When  possible,  it  will  identify  where  the  DoD  will 
have  to  eoneentrate  its  effort  to  ensure  the  transition  goes  smoothly  and  on  time. 

B,  RESEARCH  OBJECTIVE 

The  objeetive  of  this  researeh  is  to  establish  the  effeets  that  the  transition  from 
IPv4  to  IPv6  is  having  on  the  Department  of  Defense.  An  analysis  of  this  area  will  help 
determine  the  benefits  and  eoncems  of  the  transition  and  develop  guidelines  to  improve 
its  effeetiveness. 

C,  RESEARCH  QUESTIONS 

The  primary  researeh  question  is:  What  is  the  value  of  transitioning  to  IPv6?  The 
subsidiary  questions  are  as  follows: 

1 .  How  will  the  eost  of  the  new  protoeol  be  assessed  in  terms  of  eomplexity  and 
performanee? 

2.  Is  it  best  to  transition  from  the  periphery  or  the  eore? 

3.  What  risks  are  involved  with  the  transition? 

4.  Has  the  DoD  deelared  its  requirement  for  IPv6  produets? 

5.  Have  vendors  invented  new  produets  or  will  the  DoD  first  have  to  speeify  the 
requirement? 

6.  What  is  the  DoD  policy  with  regard  to  opening  the  eore  to  new  teehnology? 

D,  SCOPE,  LIMITATIONS  AND  ASSUMPTIONS 

The  seope  of  this  thesis  will  eneompass  an  analysis  of  the  DoD  IPv6  Transition 
Plan  in  order  to  evaluate  the  status  of  the  eonversion  to  IPv6.  The  study  will  explore 
various  Request  for  Comments  (RFCs)  to  establish  the  progress  of  the  plan.  A  review  of 
the  future  transition,  in  eonjunetion  with  the  information  gathered  from  outside  the  DoD, 
will  be  used  to  develop  an  analysis  of  the  plan.  This  study  was  prepared  while  the 
Enterprise  Architeeture  (EA)  was  being  generated  for  submission  to  0MB.  [0MB,  2005] 
This  limits  the  study  from  drawing  any  final  eonelusions  on  the  suceess  or  failure  of  the 
transition  plan.  This  study  is  also  limited  in  that  there  is  not  a  eomplete  inventory  of 
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existing  Internet  Protoeol  (IP)  eompliant  deviees  and  teehnologies.  This  study  assumes 
that  the  reader  has  a  general  knowledge  or  familiarity  with  internet  protoeols. 

E,  METHODOLOGY 

Multiple  researeh  methods  were  used  to  answer  the  primary  and  subsidiary 
questions.  A  broad  examination  of  the  available  literature  was  eondueted.  This 
examination  eonsisted  of  the  Naval  Postgraduate  library,  the  Internet,  and  theses  from 
various  graduate  programs. 

Interviews  were  eondueted  by  eleetronie  mail,  telephone,  and  in  person  with 
various  personnel  involved  with  eomputer  programming  and  the  managing  of  eomputer 
systems,  inside  and  outside  of  the  DoD. 

This  thesis  will  provide  a  qualitative  report  eomparing  the  transition  plan  to  the 
eurrent  and  future  status  of  DoD  systems. 

Existing  publieations  will  be  utilized  to  develop  a  risk  analysis  and  provide  risk 
mitigation  for  IPv6. 

Methodologies  needed  to  support  the  eomplieated  transition  to  IPv6,  ineluding 
teehniques  for  implementing  and  managing  the  lengthy  eoexistenee  of  both  protoeols,  are 
to  be  analyzed. 

Some  reeommendations  for  the  management  of  the  transition  to  IPv6  will  be 
derived  by  examining  DoD  poliey  on  the  introduetion  of  new  teehnology. 

F.  ORGANIZATION  OF  STUDY 

The  remainder  of  the  study  is  organized  as  follows:  Chapter  II  will  provide  a 
eomparison  of  the  two  teehnologies.  Chapter  III  will  eompare  the  original  transition  plan 
to  the  eurrent  state  of  preparedness  and  then  eonelude  with  an  analysis  of  the  proposed 
plan  to  implement  IPv6.  Chapter  IV  will  analyze  the  implementation  of  IPv6  in  the  DoD. 
Chapter  V  will  provide  the  eonelusions  and  reeommendations,  to  inelude  a  summary  of 
the  researeh  questions  and  the  value  of  the  transition. 
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II.  BACKGROUND 


A,  INTRODUCTION 

This  chapter  provides  a  broad  introduetion  about  the  transition  of  the  DoD 
eomputer  systems  from  IPv4  to  IPv6.  A  definition  of  IPv6  will  be  provided  and  the  main 
features  will  be  identified,  along  with  some  of  the  related  RFCs.  Diseussions  also  inelude 
IP  addressing,  interoperability,  weaknesses,  and  strengths  assoeiated  with  the  next 
generation  protoeol. 

Internet  Protoeol  version  4  (IPv4)  is  the  legaey  IP  that  has  been  used  by  the  DoD 
sinee  it  was  speeified  in  RFC  791  in  1981.  [Postel,  1981]  It  is  eurrently  implemented  on 
a  wide  array  of  eomputing  and  networking  platforms. 

The  Transmission  Control  Protoeol/Internet  Protoeol  (TCP/IP)  layering  model  is 
also  known  as  the  Internet  Layering  Model  or  the  Internet  Referenee  Model.  [Comer, 
2004]  It  eontains  five  layers  as  illustrated  in  Figure  1.  Among  other  eapabilities,  IPv4 
uses  a  32-bit  IP  address  and  it  allows  unique  addresses  that  number  almost  4.3  billion. 
[UNH-IOL  IPv4,  2006]  The  Internet  Layering  Model  defines  formatting  of  traffie  for 
Layer  3  and  it  uses  IPv4  as  the  prineipal  eneapsulation  meehanism.  The  Internet  uses 
IPv4  to  eonneet  deviees  end  to  end.  Routers  have  the  responsibility  of  forwarding 
information  aeross  heterogeneous  networks. 


Application 

^  l AYER  5 

-•  1  AYER  4 

•m  1  AYER  3 

Transport 

Internet 

•m  1  AYER  2 

Network  Interface 

lAYER  / 

Physical 

Figure  1.  The  TCP/IP  reference  model  (From:  Comer,  2004) 
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According  to  the  article  by  Harrison,  the  DoD  runs  the  largest  IP  network  in  the 
world.  [Harrison  et  ah,  2005]  The  emerging  replaeement  for  the  aging  IPv4  is  IPv6; 
however,  it  is  not  yet  widely  implemented  in  North  Ameriea.  Internet  Protoeol  version  6 
will  eoexist  with  IPv4  and  will  eventually  replaee  IPv4  in  most  networks. 

The  IP  resides  at  Layer  3  and  it  is  a  routed  protoeol.  It  takes  advantage  of  the 
routes  determined  by  the  underlying  routing  protoeols.  The  network  and  host  addressing 
seheme  of  IP  allows  for  the  differentiation  and  forwarding  of  traffie  between 
intereonneeted,  disparate  loeal  and  wide  area  network  links.  Layer  3  provides  a  standard 
means  of  transporting  data  paekets  to  eaeh  other  aeross  the  Internet.  Speeifieally,  the 
formatting  of  paekets  sent  aeross  an  internet  is  speeified  by  Layer  3  protoeols.  It  also 
speeifies  the  meehanisms  used  to  forward  paekets  from  the  souree,  through  one  or  more 
routers,  to  a  final  destination.  [Comer,  2004] 

The  strueture  of  the  US  Internet  arehiteeture  is  set  up  to  where  it  has  little 
problem  with  the  address  spaee  under  IPv4.  Other  eountries  of  the  world  have  a  lesser 
alloeation  of  the  IP  address  spaee  [Charny,  2003],  so  the  rest  of  the  world  will  be  moving 
to  IPv6  as  a  means  of  mitigating  their  address  spaee  limitations.  Seeurity  holes,  among 
other  things,  will  exist  if  the  US  does  not  transition  to  IPv6,  leaving  itself  vulnerable  to 
attaek  on  many  levels.  Ensuring  a  smooth  transition  to  IPV6  will  help  proteet  US 
systems  from  the  emerging  vulnerabilities  related  to  IPv4. 

1.  What  is  IPv6? 

Internet  Protoeol  version  6  is  a  suite  of  protoeols  and  standards  developed  by  the 
IETF.  This  new  version  was  previously  ealled  IP-The  Next  Generation  (IPng).  [Davies, 
2003]  Unlike  IPv4,  IPv6  was  to  avoid  random  additions  of  new  features.  It  was  designed 
to  have  a  minimal  impaet  on  upper  and  lower  layer  protoeols.  The  IPv6  protoeol  has  a 
new  header  format,  larger  address  spaee,  effieient  and  hierarehieal  addressing  and  routing 
infrastrueture,  stateless  and  stateful  address  eonfiguration,  built-in  seeurity,  better  support 
for  QoS,  new  protoeols  for  neighboring  node  interaetion,  and  extensibility. 

The  DoD  understands  IPv6  is  a  vital  teehnology  that  will  beeome  eritieal  for  its 
ageneies.  [AIC,  2005]  There  is  an  ever  inereasing  user  requirement  that  needs  to  be 

supported,  along  with  the  IP-enabled  deviees  that  eontinue  to  flood  the  market.  In 
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addition  to  the  expanded  address  spaee,  the  new  features  of  IPv6  include  improved 
flexibility,  functionality,  and  information  routing;  enhanced  mobility  features;  and 
simplified  activation,  configuration,  and  operation  of  networks  and  services.  The  security 
is  expected  to  improve  once  IPv6  is  fully  implemented.  [AIC,  2005] 

The  document  that  instructs  DoD  agencies  to  implement  the  IPv6  protocol  is 
0MB  Memorandum  05-22.  It  is  to  be  implemented  in  the  DoD  network  backbone  by 
June  2008.  [0MB,  2005]  The  memorandum  directs  all  agencies  to  complete  two 

inventories  of  IP  devices  and  technology  (see  Appendix  A),  complete  an  IPv6  impact 
analysis  (see  Appendix  B),  and  develop  an  IPv6  transition  plan.  The  CIO  Council 
Architecture  and  Infrastructure  Committee  was  tasked  to  develop  additional  guidance  and 
to  address  the  elements  identified  in  Appendix  C.  [0MB,  2005]  An  IPv6  transition  plan 
was  to  be  submitted  by  all  agencies.  As  part  of  their  enterprise  architecture  (EA) 
assessment,  agencies  were  to  provide  a  progress  report  on  the  inventory  and  impact 
analysis  in  February  2006.  [AIC,  2005] 

2.  IPv6  Feature  Overview 

The  design  of  IPv6  guaranteed  an  evolution,  rather  than  a  radical  change,  from 
IPv4.  The  key  intention  in  the  design  of  IPv6  was  to  ease  the  transition  from  IPv4. 
Internet  Protocol  version  6  was  designed  to  interoperate  with  IPv4.  There  are  specific 
mechanisms  built-into  IPv6  that  makes  it  support  the  transition  and  compatibility  with 
IPv4.  [IPv6  Features,  2005]  According  to  the  IPv6  specification,  the  following 
categories  contain  the  primary  changes  from  IPv4  to  IPv6: 

( a)  Large  A  ddress  Space 

The  large  address  space  of  IPv6  has  been  designed  to  allow  for  multiple 
levels  of  subnets  and  address  allocation.  A  small  number  of  the  possible  addresses  are 
currently  allocated  for  use  by  hosts.  With  IPv6,  a  much  larger  number  of  addresses  are 
available.  Address-conservation  techniques,  such  as  the  deployment  of  network  address 
translation  (NAT),  are  no  longer  necessary.  [Davies,  2003] 

(b)  Efficient  and  Hierarchical  Addressing  and  Routing 
Infrastructure 

The  Internet  will  grow  and  provide  new  routing  capabilities  because  IPv6 

supports  large  hierarchical  addresses.  These  capabilities  are  not  built-into  IPv4.  Anycast 
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addresses,  whieh  allow  a  paeket  to  be  proeessed  by  any  one  of  a  set  of  designated  hosts, 
ean  be  used  for  poliey  route  seleetion.  It  has  seoped  multieast  addresses  whieh  provide 
improved  sealability  over  IPv4  multieast.  The  "plug  and  play"  installation  is  provided  by 
loeal  use  address  meehanisms.  [ANML,  2003] 

(c)  New  Header  Format 

Some  IPv4  header  fields  have  been  dropped.  Others  have  been  made 
optional  to  reduee  the  neeessary  amount  of  paeket  proeessing  and  it  limits  the  bandwidth 
eost  of  the  IPv6  header.  As  IPv4  headers  and  IPv6  headers  are  not  interoperable,  a  host 
or  router  must  exeeute  in  both  IPv4  and  IPv6  protoeols  in  order  to  reeognize  and  proeess 
both  header  formats.  The  IPv6  addresses  are  four  times  as  large  as  IPv4  addresses; 
however,  the  new  IPv6  header  is  only  twiee  as  large  as  the  IPv4  header.  [ANML,  2003] 

(d)  Improved  Support  for  Extensions  and  Options 

IPv6  ean  be  extended  for  new  features  by  adding  extension  headers  after 
the  IPv6  header.  [Davies,  2003]  IPv6  has  more  effieient  forwarding  and  less  stringent 
limits  on  the  length  of  options.  This  is  provided  by  the  header  options  that  are  eneoded  in 
sueh  a  way  as  to  allow  greater  flexibility  for  introdueing  new  options  in  the  future.  As 
noted  earlier,  some  fields  of  an  IPv4  header  have  been  made  optional  in  IPv6.  [ANML, 
2003] 

(e)  Better  Support  for  QoS 

Traffie  is  handled  and  identified  by  newly  defined  IPv6  header  fields.  A 
Traffie  Class  field  prioritizes  the  traffie.  A  Flow  Label  field  enables  paekets  belonging  to 
a  partieular  traffie  flow  to  be  identified  by  routers  and  provide  speeial  handling  for  those 
paekets.  Sinee  the  traffie  is  identified  in  the  IPv6  header,  a  paeket  payload  that  is 
enerypted  with  Internet  Protoeol  Seeurity  (IPSee)  and  Eneapsulating  Seeurity  Payload 
(ESP)  ean  utilize  emerging  support  for  QoS  meehanisms.  [Davies,  2003] 

(f)  Built-in  Security 

Seeurity  is  built-into  IPv6.  The  ESP  header  and  trailer  support  options 
sueh  as  authentieation,  data  integrity,  and  data  eonfidentiality.  [ANME,  2003]  It 
provides  a  solution  for  network  seeurity  and  interoperability  between  different  IPv6 
implementations.  [Davies,  2003] 
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(g)  Stateless  and  Stateful  Address  Configuration 

Host  configuration  is  simplified  because  IPv6  supports  both  stateful  and 
stateless  address  configuration.  Stateful  address  configuration  is  when  an  automated 
address  configuration  is  accomplished  with  the  support  of  a  Dynamic  Host  Configuration 
Protocol  (DHCP)  server.  Stateless  address  configuration  is  autonomous  address 
configuration  in  the  absence  of  a  DHCP  server.  The  IPv6  addresses  are  eonfigured  for 
the  link  by  the  host  deviee  and  are  referred  to  as  link-loeal  addresses.  The  hosts  may  also 
ineorporate  addresses  derived  from  prefixes  advertised  by  local  routers  to  generate  a 
globally  unique  address.  If  there  is  no  router,  hosts  on  the  same  link  can  automatically 
configure  themselves  with  link-local  addresses  and  communicate  without  manual 
eonfiguration.  [Davies,  2003] 

(h)  New  Protocol  for  Neighboring  Node  Interaction 

A  series  of  Internet  Control  Message  Protocol  for  IPv6  (ICMPv6) 
messages  that  manage  the  interaetion  of  neighboring  nodes  (nodes  on  the  same  link)  is 
ealled  the  Neighbor  Discovery  protoeol.  The  broadeast-based  Address  Resolution 
Protoeol  (ARP),  ICMPv4  Router  Discovery,  and  ICMPv4  Redirect  messages  are  replaced 
by  Neighbor  Diseovery.  It  has  effieient  multieast  and  unicast  Neighbor  Discovery 
messages.  [Davies,  2003] 

3,  What  is  the  DoD’s  Plan  for  the  IPv6  Transition? 

The  goal  of  the  DoD  is  to  complete  the  transition  to  IPv6  for  all  DoD  networking 
by  fiscal  year  (FY)  2008.  It  should  be  done  in  an  integrated,  secure  and  effeetive  manner. 

Aceording  to  the  DoD  IPv6  Transition  Plan  of  March  2006,  all  Global 
Information  Grid  (GIG)  assets  being  developed,  procured  or  aequired  are  to  be  IPv6 
capable.  They  must  also  maintain  interoperability  with  IPv4  systems.  The  DoD  hopes  to 
build  confidence  by  transitioning  significant  portions  of  the  GIG  to  IPv6.  The  Defense 
Information  Systems  Ageney  (DISA)  is  to  aequire  and  manage  IPv6  addresses  for  DoD, 
which  includes  the  establishment  of  address  and  naming  conventions.  There  will  be  no 
IPv6  implementations  fielded  on  networks  carrying  operations  traffic  within  DoD  until 
such  time  that  the  security  concerns  are  addressed. 
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The  criteria  for  measuring  the  success  of  this  transition  are  included  in  the  new 
capabilities,  upgrades  and  legacy  milestones.  Success  will  be  determined  by  many 
things.  Among  them  will  be  the  ability  of  the  DoD  to  transition  within  the  specified 
timeframe.  The  transition  must  also  have  a  means  for  adjudicating  claims  that  an  asset 
should  not  transition  in  the  timeframe  prescribed.  There  needs  to  be  a  technical  strategy 
that  supports  IPv4/IPv6  interoperability.  There  must  be  an  identification  of  the  transition 
activities,  resources,  roles  and  responsibilities.  It  is  essential  to  have  early 
implementation  pilots,  test  beds  and  demonstrations.  Finally,  the  Information  Assurance 
(lA)  issues  must  be  resolved  for  the  transition  to  be  complete.  [Transition  Plan,  2005] 

4,  Related  Transition  Efforts  in  the  Commercial  World 

The  European  industry  is  supporting  IPv6.  They  are  manufacturing  devices, 
appliances  and  developing  applications.  Some  telephone  companies  and  Internet  Service 
Providers  (ISPs)  are  already  providing  services.  [Palet,  undated] 

Many  commercial  U.S.  organizations  initially  dismissed  IPv6  as  a  “don’t-need-it- 
now  technology.”  [Patterson,  2006]  Patterson  asserted  that  the  June  2003  DoD  mandate 
“instantly  became  the  single  most  important  driver  for  IPv6  adoption  in  the  United 
States.”  [Patterson,  2006] 

The  commercial  information  technology  (IT)  world  is  taking  hold  of  IPv6. 
Internet  Protocol  version  6  functionality  is  being  implemented  and  aggressively 
incorporated  by  many  of  the  largest  IT  vendors.  IPv6  functionality  has  been  added  to 
some  software  manufacturers’  operating  systems,  these  include  Microsoft  and  Red  Hat 
Linux.  [Patterson,  2006] 

To  establish  guidance  and  interoperability  testing  platforms,  the  North  American 
IPv6  Task  Force  (NAv6TF)  and  the  IETF  are  leading  collaborative  technical  efforts  with 
DOD  groups,  educators  and  vendors.  The  Moonv6  project  is  the  most  notable  effort. 
This  project  is  taking  place  across  the  United  States  at  multiple  locations  and  is  the 
largest  permanently  deployed  multi-partner  IPv6  network  in  the  world.  [Patterson,  2006] 
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5,  Common  Methods  Used  for  Risk  Analysis  of  Technology 
Upgrades 

Risk  analysis  is  a  systematic  use  of  available  information  to  determine  how  often 
specified  events  may  occur,  as  well  as  the  magnitude  of  their  consequences.  It  includes 
identification  of  the  sources  of  risk,  their  consequences,  and  the  likelihood  of  occurrence. 
Information  is  gained  when  analyzing  risks  and  is  helpful  when  evaluating  and  treating 
the  risks.  Acceptable  risks  are  separated  from  major  risks  by  using  information  as  input. 
[Sorby,  2003]  Risk  analysis  must  be  performed  throughout  all  of  the  phases  of  the  life  of 
the  system.  The  DoD  is  using  various  approaches  to  mitigating  the  risk  associated  with 
the  transition  to  IPv6,  but  no  one  particular  technique  has  been  identified.  Several  risk 
analysis  methods  will  be  presented  in  the  following  paragraphs. 

The  most  common  risk  analysis  methods  used  within  system  development  are 
Preliminary  Hazard  Analysis  (PHA),  Hazard  and  Operability  Analysis  (HazOp),  Fault 
Tree  Analysis  (FTA),  and  Failure  Modes,  Effects  (and  Criticality)  Analysis  (FMECA). 
[Sorby,  2003] 

Preliminary  Hazard  Analysis  (PHA)  is  used  in  the  early  design  stage  of  a  system 
in  order  to  discover  hazards  early  in  the  development  process.  [Sorby,  2003]  The  aim  is 
to  identify  safety  design  criteria  and  requirements,  and  the  identified  hazards  may  be 
assessed  in  order  to  eliminate,  reduce  or  control  them. 

Hazard  and  Operability  Analysis  (HazOp)  is  a  bottom-up  hazard  identification 
technique.  The  purpose  of  a  HazOp  study  is  to  identify  potential  hazards  and  operability 
problems  caused  by  deviations  from  the  intent  of  the  design.  [Sorby,  2003] 

Eault  Tree  Analysis  (ETA)  is  primarily  a  means  for  analyzing  causes  of  hazards, 
not  for  identifying  hazards.  [Sorby,  2003]  An  undesired  system  state  is  specified  and  the 
method  works  top-down  to  identify  all  its  possible  causes  or  combinations  of  causes. 
Preferably,  all  possible  ways  the  undesirable  event  could  occur  should  be  identified  in  the 
process. 

Eailure  Modes,  Effects  (and  Criticality)  Analysis  (EMECA)  is  a  bottom-up 
ranking  approach  to  identifying  hazards.  The  analysis  identifies  possible  failure  modes 
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of  each  component  in  the  system,  and  determines  the  causes  and  consequences  of  the 
failure  modes.  This  approach  can  identify  possible  countermeasures.  [Sorby,  2003] 

Risk  analysis  can  be  used  for  two  different  purposes  in  the  design  phase;  (1)  as  a 
tool  to  specify  requirements  or  (2)  as  a  tool  to  control  the  risk  level  against  acceptance 
criteria.  Safety  critical  faults  may  be  eliminated  or  their  occurrence  minimized  in  the 
design  phase.  The  consequences  of  a  fault  may  be  minimized,  which  may  reduce  the  risk 
[Sorby,  2003].  Risk  analysis  can  be  used  to  analyze  the  effect  of  changes  or  to  analyze 
causes  of  problems  and  accidents  in  the  operation  phase  of  the  system. 

The  DoD  is  using  a  common  approach  to  mitigating  the  risk  associated  with  the 
transition  to  IPv6,  but  not  necessarily  those  previously  identified.  Organizations  within 
the  DoD  are  identifying  sources  of  risk  and  the  consequences  are  being  studied  in 
laboratory  environments  to  determine  the  likelihood  of  occurrence.  The  organizations 
include,  but  are  not  limited  to  Joint  Interoperability  Test  Command  (JITC),  DISA,  and 
the  Federal  Aviation  Administration  (FAA).  These  organizations  will  never  be  able  to 
reduce  the  risk  to  zero,  so  they  must  determine  an  acceptable  level  of  risk.  Risks  will 
continue  to  be  analyzed  as  the  transition  evolves. 

The  Education  Department  is  linking  its  move  to  IPv6  to  more  than  200  IT 
business  cases  and  using  them  to  explain  the  impact  of  the  new  technology  on  each 
investment.  [Miller,  2006] 

The  FAA  plans  to  set  up  three  test  beds  to  see  how  well  data  packets  travel 
through  its  administrative  network  using  IPv6.  [Miller,  2006]  Mark  Powell,  the  FAA’s 
chief  technical  director,  said  that  his  office  was  setting  up  routers  to  connect  laboratories 
in  Atlantic  City,  N.J.,  Oklahoma  City,  and  Washington  over  an  IPv6  network.  Powell 
said  that  this  is  the  FAA’s  “risk  reduction  activity.”  [Miller,  2006]  The  FAA  plans  to 
look  at  the  size  of  the  routing  tables,  the  latency,  what  happens  when  IPv6  packets  are 
sent  and  what  happens  when  they  transition  to  IPv6  from  IPv4.  This  method  will  help 
the  FAA  understand  the  impact  of  IPv6  on  their  wide  area  networks  (WANs)  and  local 
area  networks  (LANs).  [Miller,  2006] 
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The  techniques  of  other  organizations  that  are  mitigating  risk  will  be  further 
developed  in  the  next  chapter. 

6,  Addressing 

(a)  IPv4  Addressing 

There  are  8  bytes,  or  32  bits,  in  an  IPv4  address.  Computers  see  an  IP 
address  in  binary  format.  The  IPv4  address  of  1 0.0.0. 1  would  be  in  the  binary  format  of 
0000  1010  0000  0000  0000  0000  0000  0001.  It  is  written  in  dotted  decimal  simply  for 
human  readability.  [Mitchell,  undated]  Thus,  each  octet,  or  byte,  of  an  IP  address  has  a 
range  of  values  from  a  minimum  of  zero  to  a  maximum  of  255.  The  range  of  IPv4 
addresses  is  from  0.0. 0.0  through  255.255.255.255.  There  are  a  total  of  4,294,967,296 
possible  IP  addresses  for  IPv4.  [Mitchell,  undated] 

(b)  IPv6  Addressing 

There  are  16  bytes,  or  128  bits,  in  an  IPv6  address.  This  larger  size  means 
that  IPv6  supports  more  than  340,282,366,920,938,463,463,374,607,431,768,211,456 
possible  addresses  (greater  than  3.4  x  10^^).  [TechNet,  2005] 

Internet  Protocol  version  6  addresses  can  be  extensions  of  IPv4  addresses. 
The  four  bytes  to  the  right  of  an  IPv6  address  may  be  rewritten  in  the  IPv4  dotted  decimal 
notation.  For  example,  the  IPv6  address  E3D7:0000;0000:0000:5IF4;9BC8:C0A8:6420 
may  be  converted  to  the  mixed  IPV4/IPv6  notation  of 
E3D7::5IF4:9BC8:I92.I68. 100.32.  [Mitchell,  undated] 

B,  TRANSITION  FROM  IPV4  TO  IPV6 

Internet  Protocol  version  4  cannot  support  the  capabilities  necessary  to  meet 
future  combat  system  requirements.  The  transition  to  IPv6  will  allow  the  DoD  to  be  IP 
centric.  It  will  give  the  DoD  the  ability  to  have  greater  mobility,  ad-hoc  networking 
capabilities  for  dynamic  addressing,  and  security  through  the  embedded  IPSec.  [Dixon, 
undated] 

The  CIO  Council  Architecture  and  Infrastructure  Committee  (AIC)  is  tasked  with 
publishing  IPv6  implementation  guidance.  [AIC,  2005]  The  use  of  Enterprise 
Architecture  (EA)  will  be  addressed  by  this  guidance,  which  will  provide  information  on 
how  to  plan  for  the  enterprise-wide  IPv6  transition.  The  council  will  address  IPv6 
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transition  planning  best  practices,  networking  and  infrastructure,  addressing,  information 
assurance,  pilots,  testing  and  demonstrations,  applications,  standards,  and  training.  It  will 
also  address  the  IPv6  transition,  acquisition  and  procurement. 

The  Joint  Interoperability  Test  Command  (JITC)  Advanced  Internet  Protocol 
Technology  Lab  is  providing  critical  assistance  to  the  DoD’s  Defense  Information 
Systems  Agency  (DISA)  IPv6  Transition  Office  as  they  prepare  for  the  eventual  IPv6 
migration  while  maintaining  existing  IPv4  interoperability.  [Harrison  et  ah,  2005]  DISA 
is  ensuring  that  DoD  IPv6  fielding  is  coordinated,  does  not  duplicate  efforts  within  DoD 
and  does  not  introduce  interoperability  and  information  assurance  risks.  DISA  will 
acquire,  manage,  allocate,  and  control  the  necessary  IPv6  address  space  for  the  DoD. 
The  JITC,  as  the  sponsor  of  the  DoD  Interoperability  Communications  Exercise  (DICE)  i 
and  a  participant  in  the  Moonv6  exercise,  2  provides  a  venue  to  access  all  agencies  within 
DoD,  as  well  as  the  Combatant  Commands,  including  United  States  Northern  Command 
in  their  Homeland  Defense  role.  This  setting  helps  to  refine  and  validate  requirements 
and  reinforce  interoperability  as  the  steering  point  through  the  evolving  DoD  Information 
Technology  Standards  and  Profile  Registry  (DISR)  RPC.  DISA  and  the  Joint  Staff,  with 
participation  of  DoD  components  and  Services,  have  developed  a  transition  plan  leading 
to  full  IPv6  implementation  by  PY  2008.  [Harrison  et  ah,  2005] 

1.  Interoperability 

It  is  common  knowledge  among  the  IPv6  community  that  current  IPv6  hardware 
and  software  lack  fully  interoperable  mobility  and  security  implementations.  They  do  not 
interoperate  well  in  a  native  IPv6  environment  (IPv6  with  no  IPv4  functionality); 
however,  they  interoperate  well  when  they  are  used  with  IPv4/IPv6  transition 
mechanisms. 


1  DICE  replicates  a  geographically  dispersed  joint  task  force  (JTF)  environment  for  the  purpose  of 
joint  interoperability  certification  or  assessment  testing.  It  provides  a  forum  for  testing  emerging  DoD 
technologies,  allied  communications  initiatives,  regressive  testing  with  legacy  equipment  and  realistic  joint 
military  communications  training.  DICE  is  the  sole  DoD  exercise  whose  primary  purpose  is  to  generate 
joint  interoperability  certifications.  [Retrieved  on  5  April  2006  from  http://jitc.fhu.disa.mil/dice/] 

2  The  Moonv6  project  is  a  global  effort  led  by  the  North  American  IPv6  Task  Force  (NAv6TF) 
involving  the  University  of  New  Hampshire  -  Interoperability  Laboratory  (UNH-IOL),  Intemet2,  vendors, 
service  providers  and  regional  IPv6  Fomm  Task  Force  network  pilots  worldwide.  [Retrieved  on  27  March 
2006  from  http://www.moonv6.org/] 
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2,  The  RFCs 

Request  for  Comments  (RFC)  doeument  the  results  of  iterative  refinements  in 
particular  areas  of  interest  to  computer  networking  and  communications.  In  particular, 
they  go  beyond  the  local  area  network  and  data  communications  arena  and  embody  the 
process  for  creating  a  standard  for  the  Internet.  They  are  the  means  for  proposing, 
evolving,  and  publishing  new  standards  on  the  Internet.  The  IETF  reviews  these 
proposals.  [Glossary,  2006]  The  IPv6  specification  was  detailed  in  RFC  2460.  This 
document  specifies  the  basic  IPv6  header  and  the  initially  defined  IPv6  extension  headers 
and  options.  It  also  discusses  packet  size  issues,  the  semantics  of  flow  labels  and  priority, 
and  the  effects  of  IPv6  on  upper-layer  protocols.  Several  other  RFCs  define  the  IPv6 
domain,  as  indicated  below. 

IPv6  uses  the  Internet  Control  Message  Protocol  (ICMP),  as  defined  for  IPv4, 
with  a  number  of  changes.  The  resulting  protocol  is  called  ICMPv6  and  is  discussed  in 
RFC  2463. 

RFC  2529  “specifies  the  frame  format  for  transmission  of  IPv6  packets  and  the 
method  of  forming  IPv6  link-local  addresses  over  IPv4  domains.  It  also  specifies  the 
content  of  the  Source/Target  Link-layer  Address  option  used  in  the  Router  Solicitation, 
Router  Advertisement,  Neighbor  Solicitation,  and  Neighbor  Advertisement  and  Redirect 
messages,  when  those  messages  are  transmitted  on  an  IPv4  multicast  network.” 
[Carpenter  &  Jung,  1999] 

RFC  2711  “describes  a  new  IPv6  Hop-by-Hop  Option  type  that  alerts  transit 
routers  to  more  closely  examine  the  contents  of  an  IP  datagram.  This  option  is  useful  for 
situations  where  a  datagram  addressed  to  a  particular  destination  contains  information 
that  may  require  special  processing  by  routers  along  the  path.”  [Partridge  &  Jackson, 
1999] 

Stateless  IP/ICMP  Translation  Algorithm  (SIIT),  which  specifies  a  transition 
mechanism  algorithm,  is  described  in  RFC  2765.  [Gilligan  et  ah,  1996]  “The  algorithm 
translates  between  IPv4  and  IPv6  packet  headers  (including  ICMP  headers)  in  separate 
translator  ‘boxes’  in  the  network  without  requiring  any  per-connection  state  in  those 
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‘boxes’.  This  new  algorithm  ean  be  used  as  part  of  a  solution  that  allows  IPv6  hosts, 
whieh  do  not  have  permanently  assigned  IPv4  addresses,  to  communieate  with  IPv4-only 
hosts.”  [Nordmark,  2000] 

RFC  2874  “defines  ehanges  to  the  Domain  Name  System  (DNS)  to  support  the 
renumberable  and  aggregatable  IPv6  addressing.  The  ehanges  inelude  a  new  resouree 
reeord  type  to  store  an  IPv6  address  in  a  manner  whieh  expedites  network  renumbering 
and  updated  definitions  of  existing  query  types  that  return  Internet  addresses  as  part  of 
additional  section  processing.”  [Crawford  &  Huitema,  2000] 

RFC  2893  “specifies  IPv4  compatibility  mechanisms  that  can  be  implemented  by 
IPv6  hosts  and  routers.”  [Gilligan  &  Nordmark,  2000] 

The  IPv6  Tunnel  Broker  is  outlined  in  RFC  3053.  The  transitional  IPv6  global 
Internet  “uses  a  lot  of  tunnels  over  the  existing  IPv4  infrastructure.  Those  tunnels  are 
difficult  to  configure  and  maintain  in  a  large  scale  environment.”  The  development  of 
the  tunnel  broker  model  is  to  “help  early  IPv6  adopters  to  hook  up  to  an  existing  IPv6 
network”  and  “to  get  stable,  permanent  IPv6  addresses  and  DNS  name  associations.” 
[Durand,  et  ah,  2001] 

The  connection  of  IPv6  domains  via  IPv4  clouds  was  also  discussed  in  RFC  3056. 
This  RFC  “specifies  an  optional  interim  mechanism  for  IPv6  sites  to  communicate  with 
each  other  over  the  IPv4  network  without  explicit  tunnel  setup,  and  for  them  to 
communicate  with  native  IPv6  domains  via  relay  routers.”  [Carpenter  &  Moore,  2001] 

The  RFC  3142  describes  an  IPv6-to-IPv4  transport  relay  translator  (TRT).  “It 
enables  IPv6-only  hosts  to  exchange  {TCP,  UDP}  traffic  with  IPv4-only  hosts.  A  TRT 
system,  located  between  the  IPv6  and  IPv4  hosts,  translates  {TCP,  UDP}/IPv6  to  {TCP, 
UDP}/IPv4,  or  vice  versa.”  [Hagino  &  Yamamoto,  2001] 

RFC  3146  “describes  the  frame  format  for  transmission  of  IPv6  packets,  the 
method  of  forming  IPv6  link-local  addresses  and  statelessly  autoconfiguring  addresses  on 
IEEE1394  networks.”  [Fujisawa  and  Onoe,  2001] 
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There  are  many  RFCs  that  document  Internet  Standards.  Several  of  the  main 
features  of  IPv6  are  cross  referenced  with  the  related  RFCs  in  the  Table  1. 


RFC 

Title 

Function 

1752 

The  Recommendation  for  the  IP  Next  Generation 
Protocol 

IPng 

1888 

OSI  NSAPs  and  IPv6 

Addressing 

1924 

A  Compact  Representation  of  IPv6  Addresses 

Addressing 

1981 

Path  MTU  Discovery  for  IP  version  6 

Neighboring  node 
interaction 

2080 

RIPng  for  IPv6  (Routing  Information  Protocol) 

Built-in  Security  /  QoS 

2373 

IP  Version  6  Addressing  Architecture 

Efficient  and  Hierarchical 
Addressing  and  Routing 
Infrastructure 

2374 

An  IPv6  Aggregatable  Global  Unicast  Address  Format 

Efficient  and  Hierarchical 
Addressing  and  Routing 
Infrastructure 

2401 

Security  Architecture  for  the  Internet  Protocol 

Built-in  Security 

2402 

IP  Authentication  Header 

New  Header  Format  / 
Extensibility  /  Security 

2406 

IP  Encapsulating  Security  Payload  (ESP) 

New  Header  Format  / 
Extensibility  /  Security 

2460 

Internet  Protocol,  Version  6  (IPv6)  Specification 
(obsoletes  RFC  1883) 

New  Header  Format  / 
Extensibility  /  Security 

2461 

Neighbor  Discovery  for  IP  Version  6  (IPv6) 

Stateless  and  stateful 
address  configuration 

2462 

IPv6  Stateless  Address  Autoconfiguration 

Stateless  and  stateful 
address  configuration 

2463 

Internet  Control  Message  Protocol  (ICMPv6)  for  the 

IPv6  Specification 

Neighboring  node 
interaction 

2464 

Transmission  of  IPv6  Packets  over  Ethernet  Networks 

Stateless  address 
configuration 

2472 

IP  Version  6  over  PPP  (Point-to-Point  Protocol) 

Extensibility 

2474 

Definition  of  the  Differentiated  Services  Field  (DS  Field) 
in  the  IPv4  and  IPv6  Headers 

New  Header  Format 

2526 

Reserved  IPv6  Subnet  Anycast  Addresses 

Addressing 

2529 

Transmission  of  IPv6  over  IPv4  Domains  without 

Explicit  Tunnels 

Addressing  and  Routing 
Infrastructure  /  Neighboring 
node 

2545 

Use  of  BGP-4  Multiprotocol  Extensions  for  IPv6  Inter- 
Domain  Routing 

Extensibility  /  Addressing 

2675 

IPv6  Jumbograms 

New  Header  Format  / 
Extensibility 

2711 

IPv6  Router  Alert  Option 

New  Header  Format  / 
Extensibility 

2740 

OSPF  for  IPv6 

Efficient  and  Hierarchical 
Addressing  and  Routing 
Infrastructure 

2765 

Stateless  IP/ICMP  Translation  Algorithm 

Stateless  address 
configuration 

2858 

Multiprotocol  Extensions  for  BGP-4 

Extensibility 
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RFC 

Title 

DNS  Extensions  to  Support  IPv6  Address  Aggregation 

Function 

2847 

and  Runumbering 

Extensibility 

2893 

Transition  Mechanisms  for  IPv6  Hosts  and  Routers 

Routing  Infrastructure 
Addressing  and  Routing 

2894 

Router  Renumbering  for  IPv6 

Privacy  Extensions  for  Stateless  Address 

Infrastructure 

Extensibility  /  Stateless 

3041 

Autoconfiguration  in  IPv6 

address  configuration 

3053 

IPv6  Tunnel  Broker 

Routing  Infrastructure 
Efficient  and  Hierarchical 
Addressing  and  Routing 

3056 

Connection  of  IPv6  domains  via  IPv4  Clouds 

Infrastructure 

3142 

An  IPv6-to-IPv4  Transport  Relay  Translator 
Transmission  of  IPv6  Packets  over  IEEE  1394 

Routing  Infrastructure 
Link-local  addresses  and 

3146 

Networks 

stateless  autoconfiguration 
Efficient  and  Hierarchical 

3484 

Default  Address  Selection  for  IPv6 

Addressing 

3627 

Avoiding  ping-pong  packets  on  point-to-point  links 

Routing 

New  Header  Format  / 

3775 

Mobility  Support  in  IPv6 

Addressing  /  Security 
Neighboring  node 

4007 

IPv6  Scoped  Address  Architecture 

interaction 

Extensibility  /  Routing 

4191 

Default  Router  Preferences  and  More-Specific  Routes 

Intra-Site  Automatic  Tunnel  Addressing  Protocol 

Infrastructure 

Efficient  and  Hierarchical 
Addressing  and  Routing 

4214 

(ISATAP) 

Internet  Protocol  Version  6  (IPv6)  Addressing 

Infrastructure 

4291 

Architecture 

Addressing 

Table  1,  IPv6  Features  Cross  Referenced  with  the  Related  RFCs 


C.  COST 

There  is  no  way  to  tell  the  future  costs  related  to  the  transition,  but  there  are  a  few 
estimates  that  have  been  published.  Many  organizations  are  unaware  of  the  capabilities 
of  IPv6.  Patterson  says  that  the  Government  should  view  IPv6  as  something  they  “ought 
to  do”  rather  than  something  they  have  to  do.  [Patterson,  2006] 

RTI  International  has  estimated  the  Government  specific  cost  for  the  transition  at 
about  five  billion  dollars  over  25  years.  [Gallaher,  2006]  They  indicate  that  the  most 
costly  single  year  will  be  somewhere  at  the  midpoint  of  the  transition,  at  a  cost  of  about 
$600  million.  [Jackson,  April  2006]  The  primary  cost  drivers  will  be  training  and 
manpower  for  testing  and  operations,  rather  than  equipment. 
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Another  estimate  was  provided  by  Patterson  and  he  estimated  that  it  will  eost 
organizations,  to  inelude  Government  specifie  eosts,  approximately  $1  billion  a  year  for 
the  next  25  years  to  transition  from  IPv4  to  IPv6.  [Patterson,  2006]  He  said  that  the  new 
protocol  could  generate  $10  billion  in  cost  savings  and  additional  services  value  every 
year.  [Patterson,  2006]  According  to  Patterson,  for  every  dollar  invested  in  IPv6,  an 
organization  could  expect  a  $10  return  in  cost  savings.  Only  about  eight  cents  per  dollar 
is  projected  to  be  used  for  the  actual  infrastructure  upgrade.  The  remaining  92  cents  will 
be  used  by  taking  advantage  of  IPv6.  The  demonstrated  cost  savings  are  in  four  main 
areas:  improved  security,  increased  efficiency,  enhancements  to  existing  applications  and 
creation  of  new  Internet-driven  applications.  This  data  comes  from  an  economic  analysis 
done  for  the  Commerce  Department  by  scientific  researcher  RTI  International  of 
Research  Triangle  Park,  North  Carolina. 

D,  THINGS  WE  NEED  TO  KNOW 

It  is  important  to  study  the  performance  of  IPv6  equipment.  Chapter  III  will 
discuss  risks  associated  with  recovery  times  for  failures,  the  speed  of  routing,  memory 
requirements,  and  QoS  issues.  The  speed  of  routing  will  need  to  be  analyzed  for  its  affect 
on  the  DoD.  Address  routing  protocols,  end  to  end  paths,  forwarding,  and  lookup  table 
implementations  are  just  a  few  of  the  risks  that  need  to  be  examined. 

E.  STANDARDS 

New  protocols  are  still  works  in  progress.  The  IETF  has  completed  more  than 
100  standards  defining  the  IPv6  protocols.  The  Tech  Watch  Report  indicates  that  there 
are  six  active  IETF  working  groups  still  producing  new  IPv6  standards.  (Tech  Watch 
Report,  2006)  The  legacy  technologies  will  be  around  for  a  while  and  should  not  be 
expected  to  disappear  over  night.  The  National  Institute  of  Standards  and  Technology 
(NIST)  is  expecting  a  coexistence  for  the  next  10  to  20  years.  The  risks  with  standards 
are  that  they  may  not  be  consistent.  It  is  possible  that  a  standard  has  wriggle  room. 
Meeting  the  standard  may  be  possible  without  meeting  the  spirit  of  the  standard.  For 
example,  devices  implementing  the  standard  may  conform  to  those  standards,  yet  may 
not  be  interoperable. 
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F.  CONCLUSION 

Chapter  II  provided  information  about  IPv4  and  introdueed  IPv6.  It  identified 
some  of  the  issues  indieating  how  the  world  has  outgrown  IPv4.  Internet  Protoeol 
version  6  promises  great  things  for  the  future;  however,  only  the  future  will  reveal  its  true 
potential.  The  erueial  issue  for  the  DoD  is  how  to  transition  from  IPv4  to  IPv6.  Chapter 
III  will  diseuss  the  original  transition  plan  and  identify  the  eurrent  state  of  preparedness. 
The  risks  related  to  the  transition  will  be  reviewed  to  determine  whether  or  not  the  DoD 
should  transition  to  IPv6  by  June  2008.  The  remainder  of  the  ehapter  will  be  dedieated  to 
the  analysis  of  the  implementation  plan. 
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III.  IPV6  TRANSITION  PLAN 


A,  INTRODUCTION 

This  chapter  presents  the  plans,  preparedness,  and  implementation  efforts  related 
to  transitioning  DoD  systems  from  IPv4  to  IPv6.  It  will  outline  how  the  original  plan 
evolved  and  deseribe  why  the  DoD  needed  to  be  the  lead  agent  for  ehange  in  the  United 
States  (U.S.).  The  primary  objeetive  is  to  understand  how  prepared  the  DoD  is  to  make 
the  transition  by  June  2008.  The  objeetive  will  allow  this  ehapter  to  eonelude  with  an 
analysis  of  the  ongoing  IPv6  implementation  efforts. 

B,  ORIGINAL  TRANSITION  PLAN 

The  DoD  Transition  Plan  deseribes  the  overall  strategy  for  the  DoD’s  migration 
from  IPv4  to  IPv6.  [Offiee  of  ASD,  2005]  It  identifies  roles  and  responsibilities  and 
establishes  the  foundation  for  more  in-depth  efforts. 

The  efforts  intend  on  accomplishing  the  transition  through  a  number  of  elements 
that  protect  interoperability,  performanee  and  seeurity.  Among  other  efforts,  the  IPv6 
eapability  must  be  baekwards  eompatible  with  IPv4.  [Office  of  ASD,  2005]  The  IPv6 
capability  is  also  required  for  all  proeurements  and  purehases  of  IT  or  IT  development 
aetivities.  Another  related  effort  was  tasked  to  the  Component  Aequisition  Executives 
(CAEs)  and  CIOs.  They  are  responsible  for  ensuring  the  implementation  of  the 
proeurement  poliey.  There  is  an  effort  outlined  in  the  plan  for  the  DoD  to  reaeh  out  to 
vendors  that  will  partieipate  in  forums  sueh  as  Armed  Eorces  Communieation  and 
Eleetronies  Assoeiation  (AECEA),  Consumer  Eleetronics  Assoeiation  (CEA)  and  North 
Ameriean  IPv6Task  Eoree  (NAv6TE).  [Offiee  of  ASD,  2005]  Other  details  regarding 
the  levels  of  effort  can  be  further  reviewed  in  the  Office  of  Assistanee  Seeretary  of 
Defense  (ASD)  Transition  Plan  of  Mareh  2005. 

The  Offiee  of  ASD  Transition  Plan  eontains  guidance  for  obtaining  IPv6  eapable 
produets  and  the  waiver  proeess  when  products  or  assets  eannot  meet  transition 
objeetives.  It  ineludes  guidanee  for  early  IPv6  pilot  implementations,  responsibilities  and 
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considerations  for  transitioning  networks,  applieations,  and  infrastructure.  It  establishes 
the  criteria  for  demonstrating  transition  readiness  and  a  strategy  for  leveraging  ongoing 
eommereial  IPv6  work. 

The  Transition  Plan  instruets  that  the  DoD  develop  recommended  network  and  I A 
designs,  which  includes  the  addition  of  transition  meehanisms  and  overall 
implementation  schedules.  Components  were  tasked  to  develop  and  maintain  detailed 
transition  plans  for  their  systems.  DISA  was  tasked  to  lead  the  maintenance  of  the 
overall  plan. 

The  DoD  will  implement  the  transition  to  IPv6  in  phases  and  the  phases  will 
overlap.  A  milestone  in  the  testing  of  IPv6  under  the  Moonv6  projeet  happened  in 
Deeember  2005.  It  focused  on  the  aecess  layer  and  IPv4  equivalency.  The  Deeember 
event  gathered  a  large  number  of  DHCPv6  implementations  at  a  single  loeation.  It 
included  an  international  Voice  over  Internet  Protoeol  (VoIP)  call  made  over 
commercially  available  software  from  North  America  through  the  use  of  an  IPv6  to  IPv4 
tunnel.  Other  areas  of  testing  suceessfully  demonstrated  DHCPv6,  DHCPv6  prefix 
delegation,  DNS  resolution,  Voice-over-IPv6  mixed  with  data  traffie,  IPv6  mobility, 
firewall  functionality,  and  IPSec  interoperability. 

The  DoD  IPv6  Capable  Exercise  (DICE)  for  Moonv6  was  designed  to  evaluate 
the  implementation  of  IPv6  within  the  industry  from  a  produet  commercial-off-the-shelf 
(COTS)  standpoint.  The  validation  of  data  analysis  was  tasked  to  JITC.  They  also  test 
and  evaluate  proeedures  and  ereate  DOD  IPv6  Approved  Produets  Eists  (APE).  Program 
managers  select  IPv6  capable  products  tested  by  JITC  and  approved  by  the  DoD. 

Moonv6  continues  to  be  an  aetive  deployment  test  bed  for  service  providers  and 
suppliers  that  wish  to  test  and  demonstrate  IPv6  eapable  teehnology.  This  is  an  ongoing 
platform  for  global  IPv6  edueation  and  knowledge.  The  Moonv6  projeet  helps  to  build  a 
firm  foundation  of  interoperability  for  the  deployment  of  the  next-generation  internet. 

Dixon  deseribed  the  phases  the  first  will  be  test  and  analysis,  followed  by  phases 
for  initialization,  implementation  of  the  core,  co-existence  of  IPv4  and  IPv6,  and  then  the 
final  transition  to  a  native  IPv6  environment.  [Dixon,  not  dated] 
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1,  Test  and  Analysis 

The  Test  and  Analysis  phase  started  in  fiseal  year  2004  and  included  the 
assessments  of  transition  mechanisms  and  the  COTS  dual-stack  3  network  software 
upgrades.  [Pollock,  2004]  To  support  IPv6  research  and  test  requirements,  Defense 
Research  and  Engineering  Network  (DREN)  and  Defense  Information  System  Network  - 
Eeading  Edge  Services  (DISN-EES)  have  obtained  IPv6  capability. 

It  was  expected  that,  in  the  EY  05-06  timeframe,  at  least  one  core  network  would 
natively  support  IPv6  traffic.  [Pollock,  2004]  Testing  on  the  “Moonv6”  network  was 
conducted  from  24  July  2006  to  28  July  2006  at  the  University  of  New  Hampshire 
Interoperability  Eaboratory  (UNH-IOE).  [Volpe,  2006]  Business  Wire  stated  that  the 
Moonv6  network  is  the  world's  largest  multi-vendor  IPv6  network.  The  testing  resulted 
in  the  first  successful  public  demonstration  of  the  Network  Time  Protocol  (NTP)  running 
on  a  native  IPv6-only  connection.  [Volpe,  2006] 

In  the  EY  07  timeframe,  the  DoD  is  supposed  to  have  the  availability  of  High 
Assurance  Internet  Protocol  Encryptor  (HAIPE)  IPv6  capable  devices  which  will  permit 
the  transition  of  Global  Information  Grid-Bandwidth  Expansion  (GIG-BE)  and  the  DoD’s 
other  classified  core  networks  to  dual-stack  operation.  In  EY  2008,  it  was  expected  that 
IPv6  will  be  the  native  protocol  with  IPv4  being  accommodated  through  tunneling. 

The  Test  and  Analysis  phase  was  outlined  in  a  brief  by  Captain  R.  V.  Dixon.  The 
DoD  had  to  develop  a  master  plan  and  a  transition  strategy.  [Dixon,  not  dated]  The  DoD 
was  going  to  need  to  acquire  IPv6  address  space  so  that  they  could  develop  an  IPv6 
addressing  plan.  They  needed  to  plan  for  the  DNS  infrastructure  modification  and 
establish  a  DNS  root  server.  The  Defense  Information  Systems  Agency  (DISA)  was 
assigned  to  develop  an  operational  laboratory.  The  DoD  needed  an  IPv6  test  bed  to 
analyze  modifications  to  DOD  software,  perform  requirements  analysis  and  lA 
assessments.  They  needed  to  initiate  a  DOD  cost  assessment  and  develop  a  DOD  IPv6 
initiation  policy. 

'X 

^  Dual  IP  stack  networks  and/or  hosts  with  a  capability  to  handle  both  IPv6  and  IPv4.  A  dual  stack 
host  uses  a  DNS  resolver  to  determine  the  appropriate  IP  protocol  to  use  for  the  intended  recipient.  In  a 
dual  stack  network,  the  routers  can  forward  traffic  for  both  IPv4  and  IPv6  end  nodes  with  a  dual  IP  stack.” 
(DoD  IPv6  Transition  Plan,  Office  of  ASD,  March  2005) 
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2.  Initialization 

The  initialization  phase  will  require  a  eomplete  DNS  infrastructure  modification. 
[Dixon,  not  dated]  It  will  require  that  the  IPv6  test  bed  be  extended,  a  cost  assessment 
completed,  and  resources  for  information  developed.  This  will  begin  the  edge  migration 
to  dual-stack.  Core  networks  must  begin  to  translate  or  tunnel  IPv6.  Information 
assurance  functionality  and  the  application  conversion  to  dual-stack  must  begin  in  the 
initialization  phase.  The  core  migration  to  dual-stack  must  be  followed  by  the  IPv6 
network  management  capability.  This  plan  allows  for  the  initiation  of  a  dual-stack  and 
IPv6  customer  support.  For  the  remainder  of  this  phase,  the  DoD  IPv6  core 
implementation  policy  must  be  developed. 

3.  Core  Implementation 

In  this  phase,  the  core  is  to  be  migrated  to  dual-stack  so  that  IPv4  and  IPv6 
functionality  can  be  supported.  Once  completed,  the  DoD  will  introduce  IPv6  native 
capabilities  to  the  edge  of  the  network.  They  will  then  introduce  IPv6  native 
applications.  The  lA  functionality  will  be  finalized.  The  advanced  IPv6  functionality 
will  be  introduced  and  the  IPv6  network  management  capability  will  be  finalized.  The 
core  implementation  will  provide  full  support  for  dual-stack  and  IPv6.  The  next  phase 
will  require  the  development  of  the  DoD  IPv6  co-existence  policy.  [Dixon,  not  dated] 

4.  Co-Existence 

The  core  dual-stack,  edge  dual-stack,  and  the  IPv6  native  will  need  to  be 
finalized.  The  advanced  IPv6  functionality  will  be  implemented.  The  dual-stack 
application  conversions  must  be  completed  and  then  IPv6  native  application  development 
can  begin.  To  conclude  the  co-existence  phase,  they  will  develop  the  DoD  IPv6  native 
policy  as  well  as  the  DoD  legacy  IPv4  policy.  [Dixon,  not  dated]  We  will  have 
IPv4/IPv6  co-existence  for  years  to  come.  To  be  IPv6  native,  there  can  be  no 
communication  with  IPv4  systems.  The  only  way  that  IPv4  can  communicate  with  IPv6 
is  through  transition  mechanisms  or  tunneling,  which  would  make  the  system  non-native. 

5.  IPv6  Native 

During  the  IPv6  native  phase,  they  will  finalize  the  native  IPv6  applications  and 
network  devices.  They  must  ensure  complete  IPv6  functionality.  The  edge  network. 
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devices,  and  core  networks  must  be  migrated  to  native  IPv6.  If  necessary,  they  must  de- 
integrate  IPv4  and  then  translate  or  tunnel  IPv4  edge  devices/networks  through  the  core. 
[Dixon,  not  dated] 

C.  CURRENT  STATE  OF  PREPAREDNESS  OF  THE  ARMED  SERVICES 

The  approach  by  the  DoD  is  to  establish  and  participate  in  an  IP  distributed  test 
network.  They  must  have  a  realistic  implementation  and  the  architecture  to  support  it. 
They  are  looking  to  make  interoperability  the  guiding  principle.  [Dixon,  not  dated]  The 
DoD  needs  to  encourage  vendor  participation  to  insure  interoperability  with  other  IPv6 
systems  and  IPv4  systems  using  standard  applications.  The  DoD  must  be  able  to 
demonstrate  the  ability  to  use  various  transition  mechanisms.  They  also  need  to  ensure 
the  new  features  of  IPv6  are  beneficial  to  military  applications.  The  different  U.S. 
Armed  Services  have  contributed  in  the  own  ways. 

1.  Army 

The  U.S.  Army  identified  interoperability  issues  with  the  legacy  networks  and 
systems,  network  address  translation  (IPv4  /  IPv6  gateway),  and  tunneling.  [Dixon,  not 
dated]  They  leveraged  autoconfiguration  to  reduce  their  net  management  burden  and  had 
potential  enhancements  to  QoS.  The  Army  determined  they  would  have  performance 
issues  with  dual-stack  networks.  They  conducted  mobile  IPv6  experiments  and 
participated  in  the  JITC  DICE03  experiments  and  in  the  evolution  of  IPv6  policy.  They 
identified  a  potential  early  IPv6-enabled  adopter  with  the  Warfighter  Information 
Network-Tactical  Network  Operation  Center-Vehicle.  They  also  participated  in  the 
DISN  IPv6  testbed. 

2,  Navy-Marine  Corps 

The  Navy’s  IPv6  Transition  Plan  was  developed,  reviewed  and  approved  through 

the  coordination  efforts  of  the  Navy’s  IPv6  Transition  Project  Office  (NITPO)  Team  at 

the  Space  and  Naval  Warfare  Systems  Command  (SPAWARSYSCOM).  [Evans,  2005] 

The  SPAWARSYSCOM  NITPO  established  the  Navy  IPv6  Steering  Group  (NISG)  as  a 

consensus-based  team  for  development,  review  and  endorsement  of  the  Navy  IPv6 

Technical  Transition  Strategy  document.  This  was  done  under  the  direction  of  the 

Department  of  Navy  (DON)  Chief  Information  Office  (CIO)  and  sponsorship  of  Chief  of 

Naval  Operations  (CNO)  N71.  [Evans,  2005] 
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The  Assistant  Secretary  of  Defense  (Networks  &  Information  Integration)/DoD 
Chief  Information  Officer  [ASD  (NII)/DoD  CIO]  designated  Defense  Research  and 
Engineering  Network  (DREN)  as  a  DoD  IPv6  pilot  network.  It  is  an  important  DoD 
resource  for  research  and  engineering.  The  DREN  provides  connectivity  between  the 
High  Performance  Computing  Modernization  Program’s  (HPCMP's)  physically  separated 
High  Performance  Computing  (HPC)  user  sites,  HPC  Centers,  and  other  networks.  ^  The 
DREN  pilot  supports  DoD  Research  and  Development,  Test  and  Evaluation,  and 
modeling  and  simulation  for  classified  and  unclassified  uses. 

The  HPCMP  operates  DREN  for  4,500  users  in  DoD  and  related  organizations.  It 
provides  leading  edge  HPC  Centers  for  a  nation-wide  DoD  user  community  with  regard 
to  computers,  storage,  software,  scientific  visualization,  and  user  support.  It  enables  DoD 
HPC  software  use  and  it  funds  development  projects. 

Space  and  Naval  Warfare  Systems  Command  (SPAWAR)  in  San  Diego, 
California  conducted  extensive  IPv6  testing  over  the  DREN  for  three  years.  They  had  a 
test  bed  between  five  sites  running  IPv6  exclusively  with  multiple  operating  systems 
(OSs),  firmware  (EWs),  intrusion  detection  systems  (IDSs),  DNS,  simple  mail  transfer 
protocol  (SMTP),  and  file  transfer  protocol  (ETP).  They  provided  extensive  findings  and 
feedback  to  vendors  who  were  missing  functionality,  had  incompatibilities,  and  security 
concerns.  [Dixon,  not  dated] 

The  SPAWAR  Systems  Center  in  Charleston,  South  Carolina  has  been  a  principal 
participant  in  Defense  Information  System  Network  -  Eeading  Edge  Services  (DISN- 
EES)  as  part  of  the  Commander  in  Chief  21st  Century  (CINC  21)  Advanced  Concept 
Technology  Demonstration.  [Dixon,  not  dated]  They  are  running  a  dual-stack 
environment  and  have  conducted  extensive  compatibility  tests  with  multiple  technologies 
and  products.  They  share  test  results  to  provide  real-world  experience  and  to  influence 
hardware  and  software  development  and  designs. 


4  From  the  DoD  HPCMP  website  retrieved  on  19  August  2006  from 
http://www.hpcmo.hpc.mil/Htdocs/DREN/index.html 
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3,  Air  Force 

The  U.S.  Air  Force  created  the  Air  Force  IPv6  Transition  Management  Office 
(TMO)  within  the  Air  Force  Communications  Agency  to  manage  the  Air  Force’s 
migration  from  IPv4  to  IPv6.  The  agency  developed  and  updated  the  Air  Force  IPv6 
Transition  Management  Plan  to  version  2.0,  completed  IPv6  Transition  Management 
Guidelines,  was  in  progress  of  assessing  transition  costs  at  the  base  and  Air  Force 
enterprise  levels,  and  was  identifying  pilot  programs  and  test  equipment  and  locations  in 
preparation  for  the  2008  transition.  [Spaulding,  2005] 

The  Air  Force  has  also  participated  in  the  DISA-led  DOD  IPv6  transition  working 
group  and  the  DISN  IPv6  test  bed  network.  [Dixon,  not  dated]  They  promoted  the  use  of 
the  IPv6  capability  in  future  Air  Force  acquisitions.  The  Air  Force  Information  Warfare 
Center  (AFIWC)  conducted  a  security  analysis  in  coordination  with  the  National  Security 
Agency  (NSA).  They  hosted  inter-Service  IPv6  discussions.  The  Air  Force  Research 
Lab  (AFRL)  participated  in  the  University  of  Indiana’s  Abilene  IPv6  test  network.  The 
MoonV6  project  is  also  of  interest  to  the  Air  Force. 

D,  RISK  IPV6  BRINGS  TO  DOD 

There  are  risks  associated  with  the  implementation  of  IPv6.  The  next  generation 
protocol  will  touch  everything  we  do.  Figure  2.  provides  a  pictorial  of  how  IPv6  will 
impact  the  DoD  world. 
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Figure  2,  IPv6  will  Touch  Everything  [From:  Dixon,  not  dated] 
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The  DoD  intends  on  ensuring  that  IPv6  does  not  introduce  interoperability  and  lA 
risks.  [Dixon,  not  dated]  The  temporary  restriction  of  IPv6  on  networks  carrying 
operations  traffic  was  designed  to  reduce  the  risk  associated  with  interoperability  and  lA. 
Figure  3.  graphically  depicts  the  projected  DoD  timeline. 


Figure  3,  Projected  DoD  Timeline  [From:  Dixon,  not  dated] 

1,  Risk  Areas 

Risk  areas  include  software,  hardware,  technology,  cost,  schedule,  and  people. 
[Osmundson,  2006]  There  has  been  little  motivation  for  vendors  in  the  United  States  to 
develop  software  or  hardware  for  IPv6.  The  technology  is  out  there  and  is  building  up 
around  the  world,  but  it  is  not  a  priority  for  U.S.  companies.  It  could  be  cost  prohibitive 
for  many  companies,  especially  small  companies.  Individual  home  users  will  probably 
not  be  affected  by  the  transition  since  ISPs  will  most  likely  provide  their  customers  with 
a  dual-stack  transition  mechanism  that  will  carry  IPv4  traffic  onto  an  IPv6  network. 

The  DoD  has  been  directed  to  purchase  IPv6  compliant  hardware.  The  cost  is 
already  being  off-set  by  incorporating  this  strategy  into  new  purchases.  The  scheduled 
transition  is  for  June  2008,  it  is  possible  that  the  schedule  will  slip  prolonging  the  DoD’s 
risk  associated  with  IPv4  traffic  on  an  IPv6  network.  People  tend  to  be  change  averse,  so 
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they  are  a  risk  sinee  they  may  not  want  to  complete  all  the  tasks  necessary  to  change  the 
way  they  do  business.  If  it  weren’t  for  the  DoD,  there  would  be  little  concern  for 
transitioning  to  IPv6  in  the  U.S. 

2.  Effects 

The  impact  of  transitioning  to  IPv6  will  have  both  positive  and  negative  effects. 
The  DoD  will  have  to  focus  on  the  negative  impact.  The  DoD  will  have  to  analyze  those 
factors,  implement  security  measures,  and  be  willing  to  transition  to  IPv6  with  an 
acceptable  level  of  risk.  It  is  not  possible  for  the  transition  to  be  implemented  with  a  risk 
level  of  zero,  there  will  be  a  residual  amount  of  risk  the  DoD  will  have  to  cope  with  if  it 
is  ever  want  to  transition  to  IPv6. 

Experts  have  identified  several  effects  related  to  security  that  IPv6  brings  to  the 
network.  For  example,  if  Encapsulated  Security  Payload  (ESP)  Header  is  used,  the 
content  analysis  is  impossible  for  firewalls.  [IPv6,  2006]  A  connection  to  an  untrusted 
host  can  be  opened  up  from  within  a  private  network  when  used  in  tunnel  mode,  since  the 
IP  address  will  not  be  visible  to  the  firewall.  The  effect  is  that  a  system  becomes 
vulnerable  to  fraudulent  subnet  mask  replies  as  a  result  of  auto-configuration 
requirements  of  IPv6,  which  provides  an  opportunity  for  denial  of  service  (DoS)  attacks. 
Strong  cryptography  is  a  processor-intensive  task  and  security  problems  may  result  from 
the  more  complex  DNS.  It  is  important  to  remember  that  even  though  IPv6  is  designed 
to  provide  better  security,  it  does  have  some  negative  effects. 

3,  Deployment  Risk 

Although  the  transition  is  mandated  by  the  DoD,  there  is  a  chance  that  resistance 
to  change  may  cause  some  problems.  Many  producers  and  users  are  satisfied  with  the 
health  and  flexibility  of  IPv4.  The  large  amounts  of  IPv4  compatible  equipment  and 
applications  will  constrain  the  transition  to  IPv6.  Users  may  not  be  willing  to  expend 
capital  and  labor  resources  to  transition  to  native  IPv6  in  a  timely  manner.  If  they  do  not, 
there  could  be  a  security  risk  that  is  opened  up  by  an  IPv4  user  sending  traffic  through  an 
IPv6  tunnel. 
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Experts  predict  that  legacy  systems  will  continue  to  run  IPv4  for  a  long  time. 
[IPv6,  2006]  Interoperability  of  hardware  and  software  will  be  a  major  concern  for 
enterprises  interconnecting  their  networks  across  mixed  environments. 

4.  Economic  Risk 

Acquiring  an  IPv6  capability  can  be  accomplished  by  making  the  transition  a  part 
of  the  normal  technology  upgrade  or  replacement  cycle  for  the  DoD.  This  will  allow 
activities  to  absorb  the  cost  over  a  period  of  time  rather  than  all  at  once.  There  should  be 
an  extended  overlap  to  minimize  deployment  and  operational  interdependencies.  It  is 
imperative  that  IPv6  technology  be  put  in  place  with  operational  and  security  plans,  as 
well  as  training.  Labor  will  be  the  largest  cost,  since  IPv6  products  will  be  purchased 
instead  of  IPv4  products.  The  costs  will  be  related  to  the  DoD’s  existing  network 
infrastructure  and  operational  policy,  as  well  as  how  the  DoD  plans  to  connect  to  other 
entities  using  IPv6.  [IPv6,  2006] 

5.  Security  Risk 

There  will  be  an  increase  in  security  vulnerability  at  the  beginning  of  the 
transition,  according  to  experts.  [IPv6,  2006]  The  IPv6  reliance  on  auto-configuration 
and  other  capabilities  creates  new  threats  and  vulnerabilities.  As  IPv6  becomes  more 
common  among  users,  the  more  attackers  are  likely  to  turn  their  attention  to  breaching 
IPv6  security.  A  dual  standard  mode  exposes  organizations  to  increased  security  risks. 
Products  that  are  IPv6  capable  will  undoubtedly  be  attached  to  networks  regardless  of  the 
plans  or  schedules  of  organizations.  Organizations  will  need  to  develop  security  plans 
and  policies  for  managing  IPv6  traffic.  [IPv6,  2006] 

6.  Implementation  Risk 

In  order  to  implement  IPv6,  the  DoD  must  take  appropriate  steps  to  ensure  it  has 
mitigated  risk  to  an  acceptable  level.  Organizations  were  directed  to  identify  their 
infrastructure  by  an  0MB  memorandum  dated  2005.  They  also  need  to  identify  the 
scope  and  objective  for  the  implementation  of  IPv6.  Then  the  requirements  need  to  be 
analyzed,  followed  by  the  identification  of  products  and  activities.  Once  identifications 
have  been  made,  this  information  needs  to  be  passed  down  to  the  lower  levels.  The  lower 
levels  can  then  identify  the  risks  associated  with  the  requirements,  products  and  activities. 

Then,  resources  can  be  allocated  to  mitigate  the  risk,  followed  by  a  plan  that  is  reviewed 
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and  publicized  prior  to  the  exeeution  of  the  plan.  Figure  4.  presents  a  method  that  could 
be  used  to  plan  for  the  implementation  of  IPv6.  [Osmundson,  2006] 


Figure  4,  Planning  Method  [After:  Osmundson,  2006] 

7,  Technological  Risk 

Internet  Protocol  version  6  solves  the  shortage  of  Internet  addresses  in  Asia. 
There  is  a  growing  opinion  that,  by  adopting  IPv6  early,  Asia  and  the  European  Union 
will  gain  a  eompetitive  advantage  over  the  United  States.  [AT&T,  2005]  The 
teehnologieal  leadership  in  the  Internet  may  be  affected  by  the  resistanee  to  ehange  in  the 
United  States. 

E.  IPV6  STRENGTH 

One  of  the  biggest  strengths  for  the  Internet  throughout  the  world  is  that  IP 
addresses  will  be  available  for  everyone  for  just  about  any  device  imaginable.  If  the 
Earth’s  population  was  about  6.5  billion,  then  there  will  be  about  52  octillion 
(52,351,133,372,452,071,302,057,631,912)  IPv6  addresses  per  person.  [Eovering,  2006] 

F.  IPV6  WEAKNESS 

Intrusion  detection  can  be  a  problem  since  network  administrators  may  not  see  the 
need  to  worry  about  IPv6  as  long  as  their  needs  are  met  by  IPv4.  Internet  Protocol 
version  6  is  available  to  anyone  with  an  IPv4  address.  Simple  commands  in  internet 
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enabled  platforms,  that  are  IPv6  ready,  allow  users  to  fully  utilize  the  protoeol. 
Organizations  are  not  likely  to  be  prepared  to  defend  themselves  against  IPv6-based 
attaeks  if  they  are  unprepared  to  support  or  reeognize  IPv6.  It  is  just  a  matter  of  time 
before  haekers  take  advantage  of  new  IPv6  serviees.  Haekers  will  turn  this  laek  of 
understanding  about  IPv6  to  their  own  advantage.  [Warfield,  2003] 

G.  IMPLEMENTATION  OF  IPV6 

The  eomplexity  and  eost  assoeiated  with  the  transition  from  IPv4  to  IPv6  has 
slowed  the  adoption  of  IPv6.  As  a  result,  the  eoexistenee  of  these  protoeols  will  be 
required  to  support  the  migration  from  IPv4  to  IPv6  for  a  long  time. 

Carrying  the  IPv6  traffie  over  the  IPv4  network  is  the  key  strategy  in  deploying 
IPv6  at  the  edge  of  a  network.  The  full  transition  to  a  native  IPv6  baekbone  will  not 
happen  for  a  while;  therefore,  this  eoexistenee  will  permit  inaeeessible  IPv6  domains  to 
eommunieate  with  eaeh  other. 

A  white  paper  from  AT&T  in  2005  indieated  that  it  is  possible  to  run  IPv4  and 
IPv6  throughout  the  network.  They  said  it  eould  be  done  from  all  edges  through  the  eore 
or  it  ean  be  translated  between  IPv4  and  IPv6.  This  allows  hosts  eommunieating  in  IPv4 
to  eommunieate  with  hosts  running  IPv6. 

AT&T  says  that  IPv6-based  serviees  ean  be  delivered  over  a  Multi-Protoeol  Label 
Switehing  (MPLS)  eore  network.  5  These  teehniques  allow  networks  to  be  upgraded, 
while  IPv6  is  inerementally  deployed  with  little  disruption  of  IPv4  serviees.  [AT&T, 
2005] 

Enterprises  in  Asia  are  implementing  IPv6  teehnology.  Japan,  South  Korea  and 
China  have  federal  mandates  and  ineentives  for  the  private  seetor  to  adopt  IPv6.  [AT&T, 
2005]  China  is  testing  IPv6  networks  in  eities  around  the  eountry.  Every  serviee 


5  “MPLS  is  a  scheme  used  to  enhance  an  IP  network.  Routers  on  the  incoming  edge  of  the  MPLS 
network  add  an  'MPLS  label'  to  the  top  of  each  packet.  This  label  is  based  on  some  criteria  (i.e.  destination 
IP  address)  and  is  then  used  to  steer  it  through  the  subsequent  routers.  The  routers  on  the  outgoing  edge 
strip  it  off  before  final  delivery  of  the  original  packet.  MPLS  can  be  used  for  various  benefits  such  as 
multiple  types  of  traffic  coexisting  on  the  same  network,  ease  of  traffic  management,  faster  restoration  after 
a  failure,  and,  potentially,  higher  performance.”  Retrieved  on  14  July  2006  from 
http://newsroom.cisco.eom/dlls/2004/hd_051904c.html 
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provider  in  Japan  uses  the  IPv6  production  network.  South  Korea  is  working  with  the 
European  Union  to  develop  applications  and  services  using  IPv6.  [AT&T,  2005] 

Digital  mobile  devices  will  use  IPv6.  The  use  of  IPv6  is  mandated  in  Release  5  of 
the  Universal  Mobile  Telecommunications  System  standard  (UMTS)  from  the  3rd 
Generation  Partnership  Project  (3 GPP).  The  3 GPP  develops  standards  for  advanced 
mobile  networks.  The  UMTS  Release  5  mandates  IPv6  in  all  handsets  and  the  3G  ^ 
Internet  Multimedia  Subsystem  is  defined  to  run  only  on  IPv6. 

The  high  cost  of  implementing  IPv6  in  the  U.S.  has  deterred  service  providers 
from  introducing  the  new  protocol;  however,  researchers  and  vendors  in  the  U.S.  have 
exhibited  a  lot  of  interest  in  IPv6.  In  order  to  implement  IPv6,  IP  stacks  on  routers, 
switches,  networking  equipment,  servers,  hosts  and  other  end  devices  will  need  to  be 
replaced.  [AT&T,  2005] 

Internet  protocol  version  4  is  expected  to  coexist  with  IPv6.  All  agencies  should 
be  able  to  run  both  IPv4  and  IPv6  on  the  network  using  a  dual-stack.  They  should  also  be 
able  to  encapsulate  packets  from  one  IP  version  to  the  other.  Finally,  agencies  will  need 
to  maintain  address  translation  to  ensure  IPv4  packets  are  readable  to  IPv6  networks  and 
vice  versa.  [Lost,  2006] 

The  Defense  Information  Systems  Agency  (DISA)  is  implementing  IPv6  over 
existing  DISN  core  infrastructure’s  MPLS  IPv4  backbone.  [Choi,  2006]  They  are  using 
dual-stack  unclassified-provider  edge  (U-PE)  routers.  They  will  use  dual-stack  access 
routers  as  the  customers  demand  service.  The  provider  (P)  router  functions  will  remain 
IPv4.  The  IPv6  routing  architecture  /  policy  will  remain  the  same  as  the  DISN  core  IPv4. 


6  “The  3G  (or  3-G)  is  short  for  third-generation  technology.  It  is  usually  used  in  the  context  of  cell 
phones.  The  services  associated  with  3G  provide  the  ability  to  transfer  both  voice  data  (a  telephone  call) 
and  non-voice  data  (such  as  downloading  information,  exchanging  email,  and  instant  messaging).” 
Retrieved  on  14  July  2006  from  http://en.wikipedia.org/wiki/3G 
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You  can  see  an  illustration  of  the  DISN  IPv6  transition  in  the  NIPRNet  ^  Diagram  shown 
in  Figure  5. 


Choi  described  the  three  concentric  clouds,  seen  in  Figure  5.  as  the  IPv6 
architecture  of  the  NIPRNet.  [Choi,  2006]  He  said  that  the  MPLS  core  of  provider  (P) 
routers  is  represented  by  the  inner  cloud.  The  P  routers  will  not  require  IPv6  since  they 
will  only  transport  MPLS  packets.  The  management  of  P  routers  will  be  through  IPv4. 
The  unclassified  provider  edge  routers  (U-PE)  are  represented  by  the  middle  cloud 
surrounding  the  inner  cloud.  These  U-PE  routers  support  both  IPv4  and  IPv6  on  their 
“outer”  interfaces  and  they  are  dual-stacked.  The  aggregation  layer  of  Hub  routers  is 
represented  by  the  outer  cloud.  The  aggregation  layer  will  be  dual-stacked  only  if  a 


7  “NIPRNET  stands  for  Unclassified  but  Sensitive  Internet  Protocol  Router  Network.  It  was  “formerly 
called  the  Non-secure  Internet  Protocol  Router  Network.”  The  NIPRNET  is  a  network  of  Internet  protocol 
routers  owned  by  the  Department  of  Defense  (DOD).  Created  by  the  Defense  Information  Systems  Agency 
(DISA),  NIPRNET  is  used  to  exchange  unclassified  but  sensitive  information  between  "internal"  users  as 
well  as  providing  users  access  to  the  Internet.  Retrieved  on  21  July  02  from 
http  ://en.  Wikipedia.  org/wiki/NIPRNET. 
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customer  requires  IPv6  serviee  from  a  serviee  delivery  node.  ^  The  customer  edge  (CE) 
routers  are  outside  the  three  elouds.  The  NIPRNet  will  connect  to  an  ISP  through  U-PE 
routers.  Choi  says  that  the  P,  U-PE  and  Hub  routers  will  all  be  part  of  the  same 
autonomous  system  (AS).  He  lists  the  protoeols  between  router  types  as  follows  [Choi, 
2006]; 

-  External  Border  Gateway  Protoeol  (eBGP)  will  service  CE  to  Hub,  CE  to 
U-PE  and  ISP  to  NIPRNet  router  communieations 

-  Internal  BGP  (iBGP)  and  Intermediate  System  to  Intermediate  System  (IS¬ 
IS)  will  service  Hub  to  U-PE  and  U-PE  to  U-PE  communieations. 

Request  for  Comment  4577  (REC  4577)  indicates  that  many  ISPs  offer  Virtual 
Private  Network  (VPN)  serviees  to  their  customers.  It  indicates  that  the  DISA  technique 
will  work  where  the  CE  routers  are  routing  peers  of  PE  routers.  The  Border  Gateway 
Protoeol  (BGP)  needs  to  be  used  to  distribute  the  customer's  routes  aeross  the  provider's 
IP  backbone  network.  To  tunnel  eustomer  packets  aeross  the  provider's  backbone,  the 
RPC  indieates  that  MPES  will  need  to  be  used.  The  RPC  describes  this  as  a  "BGP/MPLS 
IP  VPN".  It  is  presumed  in  the  base  specifieation  for  BGP/MPES  IP  VPNs  that  the 
routing  protocol  on  the  interfaee  between  the  PE  router  and  the  CE  router  is  BGP. 

The  plan,  as  laid  out  by  DISA,  shows  that  the  meehanics  can  work  and  are  backed 
up  by  REC  4577.  The  final  piece  of  the  puzzle  is  whether  or  not  they  can  get  IPv6 
developed,  tested,  with  an  lA  eertification,  and  deployed  by  June  2008.  Pigure  6.  shows 
the  NIPRNet  schedule  for  the  DISN  IPv6  transition. 


8  “A  small  number  of  news  aggregators  have  the  ability  to  register  to  clouds,  a  web  service  that 
notifies  the  aggregator  of  updates  to  a  feed,  eliminating  the  need  for  periodic  polling.  This  approach 
attempts  to  produce  a  more  efficient  use  of  bandwidth,  though  the  overhead  associated  with  registering  a 
cloud  can  mean  no  net  savings.  It  also  introduces  issues  of  scalability  and  a  single  point  of  failure  among 
others.”  Retrieved  on  2 1  July  02  from  http://en.wikipedia.org/wiki/Aggregator. 
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Develop  v6  Engineering  Facility 

Integration  Engineering  Tests 

DNS  v4/v6 

lA  Certification 


Milestone  Objective  3 


Deploy  Dual-Stack 

Teleport/ITSDN 

Comm/Auth  Server 


Transition  NIPR  /  SIPR  Services  to  New  DISN  Core 

*  Secret  [formerly  Secure]  Internet  Protocol  Router  Network  SIPRNet  transition  shifts  right 
two  years  for  High  Assurance  Internet  Protocol  Encryptor  (HAIPE)  availability. 


Figure  6,  NIPRNet  Schedule  for  the  DISN  IPv6  Transition  [From:  Choi,  2006] 


The  aggressive  schedule  shown  in  Figure  6.  provides  a  pictorial  of  the  challenges 
ahead  for  implementing  IPv6  by  June  2008.  One  of  the  significant  issues  often 
overlooked  is  lA.  Without  lA,  the  DoD  risks  the  chance  of  being  infiltrated  straight  to 
the  core  of  its  communication  network. 

H.  CONCLUSION 

Chapter  III  provided  a  look  at  the  original  DoD  transition  plan,  the  state  of 
preparedness,  and  some  of  the  risks  involved  with  the  implementation  of  IPv6.  It 
identified  an  approach  to  implementing  IPv6  throughout  the  DoD.  The  implementation 
of  IPv6  is  complex  and  will  cost  a  lot  of  money  to  make  the  transition  from  IPv4.  A 
course  of  action  developed  by  DISA  was  presented  as  a  viable  option  for  implementing 
the  transition.  However,  the  implementation  of  IPv6  has  been  delayed  in  the  U.S.  as  a 
result  of  the  life  extension  provided  to  IPv4.  A  smooth  transition  and  coexistence 
between  IPv4  and  IPv6  will  require  more  development.  The  question  still  remains  to  be 
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answered  as  to  whether  or  not  the  DoD  will  aetually  be  able  to  make  the  transition  from 
IPv4  to  IPv6  by  June  2008.  Chapter  IV  provides  and  analysis  of  the  DoD  implementation 
of  IPv6. 


37 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


38 


IV.  ANALYSIS 


A,  INTRODUCTION 

This  chapter  provides  an  analysis  of  the  information  colleeted  with  regard  to  the 
implementation  of  IPv6.  A  transition  strategy  will  be  discussed  to  outline  how  at  least 
one  segment  of  the  DoD  is  approaehing  the  transition.  This  will  provide  insight  into  the 
level  of  effort  being  applied  and  detail  why  it  is  vital  to  the  future  of  DoD  operations  to 
transition  to  IPv6.  It  will  also  be  used  to  address  an  issue  that  may  have  been  overlooked 
by  the  planners  of  the  transition.  This  ehapter  will  review  the  position  of  industry 
personnel  on  the  importance  of  a  smooth  transition  to  IPv6,  but  not  necessarily  as  soon  as 
2008.  The  viability  of  current  equipment,  security,  and  economics  will  be  discussed  as  it 
pertains  to  the  role  of  the  U.S.  Government  during  the  transition  to  IPv6.  The  first 
section  of  the  chapter  will  cover  on-going  transition  efforts  and  the  seeond  seetion  will 
discuss  the  identification  of  potential  risks  from  a  systems  engineering  perspeetive. 

B,  ON-GOING  TRANSITION  EFFORTS 

1,  Analysis  of  the  Ipv6  Implementation 

The  DoD  IPv6  transition  schedule  depends  upon  completion  of  the  transition  of 
NIPRNet  and  SIPRNet  (Seeret  Internet  Protoeol  Router  Network)  serviees  to  the  “new” 
eore.  [Choi,  2006]  The  IPv6  transition  should  follow  a  systems  engineering  approach,  as 
complex  problems  often  have  more  than  one  solution  and  not  all  of  them  ean  be 
completely  solved.  The  systems  engineering  approaeh  takes  this  issue  into  account. 

Systems  engineering  may  be  seen  as  an  analysis  of  the  system  functional 
behavior,  which  requires  the  system  to  be  partitioned  into  functional  areas.  [Osmundson, 
2006]  The  mission  needs  statement  help  identify  the  functional  requirements,  document 
the  functional  baseline,  and  determine  the  functional  interfaces.  Once  the  top-level  needs 
statement  and  functional  baseline  are  analyzed,  the  requirement  statements  ean  be 
developed.  Then  the  requirements  must  flow  down  to  lower  levels  so  that  they  can  be 
balanced  aeross  the  entire  system  and  changes  ean  be  negotiated.  The  approach  demands 
that  all  requirements  be  traeked  in  a  traceability  matrix.  The  funetional  analysis  and 
requirements  analysis  may  then  need  to  be  verified. 
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Choi  proposed  that  the  IPv6  transition  follow  a  systems  engineering  approaeh  and 
he  developed  task  names,  deseriptions  and  sehedules.  [Choi,  2006]  Those  tasks  are  as 
follows: 

The  “Planning  and  Engineering“  task  establishes  the  general  and  speeifie 
requirements.  This  task  should  have  eovered  the  January  2006  through 
September  2006  timeframe.  The  “Develop  v6  Engineering  Eaeility”  task 
augments  the  existing  test  bed  that  supports  integration  engineering  and 
sustainment  aetivities  by  ineluding  IPv6-related  hardware,  software  and 
topologies.  The  task  should  have  eovered  the  January  2006  through 
September  2006  timeframe.  The  “Integration  Engineering  Tests”  task 
should  inelude  all  aetivities  normally  performed  prior  to  the  release  of  a 
eonfiguration  ehange  to  the  operational  network.  The  task  eovers  the  July 
2006  through  Mareh  2008  timeframe.  The  “Domain  Name  System  (DNS) 
v4/v6”  task  should  establish  an  IPv6  DNS  infrastrueture  on  the  operational 
network.  The  task  eovers  the  August  2008  through  November  2008 
timeframe.  The  “Information  Assuranee  (lA)  Certifieation”  task  should 
inelude  those  items  required  to  reaeh  an  Authority  to  Operate  (ATO).  The 
task  eovers  ealendar  year  2007.  The  “Deploy  Dual-Staek”  task  ineludes 
all  aetivities  required  to  deploy  IPv6  serviee  on  the  operational  network. 

The  task  eovers  the  April  2008  through  June  2008  timeframe.  The 
“Teleport/ITSDN”  task  ineludes  all  aetivities  required  to  deploy  both 
Teleport  and  Integrated  Tactieal  Strategie  Data  Network  (ITSDN)  serviee 
on  the  operational  network.  The  task  should  take  plaee  during  July  2008. 

The  “Communieation/Authorization  Server”  task  ineludes  all  aetivities 
required  to  deploy  “CommServer”  serviee  on  the  operational  network.  The 
task  should  take  plaee  during  August  2008. 

The  IPv6  transition  plan  developed  an  approaeh;  however,  it  was  not  to  the  extent 
of  the  systems  engineering  approaeh  laid  out  by  Osmundson  and  Choi.  The  Navy’s 
transition  strategy  will  now  be  diseussed  to  determine  whether  or  not  the  Choi  approaeh 
was  followed. 

2.  A  Transition  Strategy 

Computer  and  network  infrastrueture  is  impaeted  greatly  by  the  transition  to  IPv6. 
The  DoD  must  field  an  IPv6  eapability  and  support  the  requirements  of  the  legaey  IPv4 
infrastrueture.  This  is  a  ehallenge  that  the  DoD  faees  in  its  quest  for  the  deployment  of 
IPv6.  The  DoD  plans  to  transition  to  the  use  of  IPv6  by  having  an  IPv4/IPv6  dual-staek 
eapability  by  fiseal  year  2008.  They  began  to  buy  IPv6  eapable  equipment  in  2003. 
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Future  applications  and  services  for  both  IPv4/IPv6  must  be  developed  in  the  U.S., 
especially  since  they  are  already  being  researched  by  Europe  and  Asia. 

The  GIG  architecture  FORCEnet  and  Network  Centric  Warfare  (NCW) 
concepts  of  operation  all  indicate  that  there  is  an  authoritative  push  to  enhance  the  IP 
based  network  capability.  The  Navy  began  moving  to  an  IP  based  network  in  the  1990s 
to  connect  the  fleet  with  the  DoD  infrastructure  ashore.  The  capabilities  ashore  were 
extended  to  provide  the  NIPRNet,  SIPRNet  and  JWICS  (Joint  Worldwide  Intelligence 
Communications  System)  capabilities  in  the  fleet. 

As  mentioned  earlier,  the  Navy  IPv6  Technical  Transition  Strategy  was  developed 
by  the  NITPO  Team  at  SPAWARSYSCOM.  [Evans,  2005]  The  Navy’s  IPv6  Technical 
Transition  Strategy  was  aligned  with  the  DoD  guidance  provided  to  Component  Services 
in  the  DoD  IPv6  Transition  Plan  of  24  March  2005.  This  strategy  established  the  Navy’s 
IPv6  program  baseline.  It  identified  the  critical  infrastructure  and  defined  a  course  of 
action  for  the  transition  of  the  capabilities.  The  IPv6  transition  is  aligned  with  the 
FORCEnet  transformation  along  with  architecture,  standards  processes,  implementation 
and  planning  guidelines.  The  Navy  program  managers  were  provided  information  on 
accurate  budget  submissions,  risk  reduction  and  IPv6  capable  products. 

The  Navy’s  strategy  includes  a  transition  approach  that  accounts  for  key  Navy 
programs  /  systems  with  identified  critical  infrastructure  as  early  adopters  for  transition  to 
IPv6.  They  will  use  dual-stack  networks,  addressing  plans,  deployment  product  lists, 
evaluation  and  certification,  intermediate  transition  mechanisms  and  then  the  final 
transition. 

9  “The  GIG  vision  implies  a  fundamental  shift  in  information  management,  eommunieation,  and 
assuranee.  The  GIG  will  provide  authorized  users  with  a  seamless,  seeure,  and  intereonneeted  information 
environment,  meeting  real-time  and  near  real-time  needs  of  both  the  warfighter  and  the  business  user.” 
Retrieved  in  5  August  2006  from  http://www.nsa.gov/ia/industry/gig.efm?MenuID=10.3.2.2 

10  “FORCEnet  is  the  operational  eonstruet  and  arehiteetural  framework  for  Naval  Warfare  in  the 
Information  Age  whieh  integrates  Warriors,  sensors,  networks,  eommand  and  eontrol,  platforms  and 
weapons  into  a  networked,  distributed  eombat  foree,  sealable  aeross  the  speetmm  of  eonfliet  from  seabed  to 
spaee  and  sea  to  land.”  From  the  CNO’s  Strategie  Study  Group  -  XXI  definition  from  22  July  02  CNO 
Briefing. 

1 1  NCW  is  “an  information  superiority-enabled  eoneept  of  operations  that  generates  inereased  eombat 
power  be  networking  sensors,  deeision  makers,  and  shooters  to  aehieve  shared  awareness,  inereased  speed 
of  eommand,  higher  tempo  of  operations,  greater  lethality,  inereased  survivability,  and  a  degree  of  self- 
synehronization.”  [Alberts,  et  ah,  2000] 
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The  Navy  has  a  high  level  description  of  the  architecture  for  the  transition  to  IPv6 
within  the  context  of  enterprise  IT.  The  architecture  includes  the  implementation  of  the 
GIG  and  FORCEnet,  where  they  focus  on  technical  architectures  and  standards  for  the 
IPv6  transition  at  the  network  layer.  The  IP  addressing  plans  will  be  developed  and 
implemented  in  phases. 

The  Navy  created  guidelines  on  the  selection  of  a  limited  subset  of  IPv6  transition 
mechanisms  for  dual-stack  and  tunneling  to  reduce  cost,  time  and  risk  for  migration  from 
IPv4.  They  have  guidance  on  specific  steps  to  deploy  IPv6.  A  deployment  product  list 
was  provided  to  organizations  so  that  they  would  have  a  preferred  product  list  and 
certification  from  which  to  work.  The  core-to-edge  deployment  of  the  core  critical 
infrastructure  will  be  conducted  in  advance  of  edge  applications.  The  Navy  guidance 
also  includes  training  and  operational  deployment  impacts  to  the  warfighter,  test, 
evaluation  and  certification. 

As  the  Navy  moves  closer  to  implementation,  its  transition  strategy  will  continue 
to  evolve.  The  Navy's  overall  transition  approach  will  occur  with  an  initial  phase 
followed  by  an  intermediate  phase  and  concluding  with  the  final  transition.  [Evans, 
2005]  This  approach  is  touted  to  reduce  the  cost,  risk,  technical  and  scheduling  impacts 
associated  with  migration  of  IPv4  to  IPv6  over  an  extended  period  of  time.  The  strategy 
is  aligned  with  funding  cycles  that  allow  for  IPv6  technical  refresh  to  occur  over  an 
extended  period.  The  Navy’s  goal  is  to  have  the  Navy's  networking  infrastructure 
accommodate  both  emergent  IPv6  and  legacy  IPv4  traffic. 

3.  Testing 

The  United  States  could  isolate  itself  from  the  benefits  of  foreign  IPv6 
deployments  and  /  or  test  beds.  The  DoDs  fixed  foundation  of  IPv4  equipment  and 
applications  could  act  as  a  wall  with  regard  to  its  transition  to  IPv6.  It  is  possible, 
although  unlikely;  that  investors  and  vendors  might  not  be  able  to  develop  new  services 
based  on  IPv6  or  may  decide  to  participate  in  other  market  areas.  [IPv6,  2006] 

The  implementation  of  IPv6  through  conformance  testing  for  the  standards  can 
and  is  being  completed  by  the  DoD  in  conjunction  with  the  private  sector  and  other 

entities.  The  “Technical  and  Economic  Assessment  of  IPv6”  report  indicated  that 
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solutions  to  interoperability  problems  ean  be  addresses  by  the  DoD  by  continuing  and 
even  expanding  its  coordination  and  funding  of  research.  [IPv6,  2006]  Protocols, 
conformance  testing  methods,  and  roadmap  processes  are  critical  for  IPv6  systems 
developers  and  implementers.  The  report  also  proposed  that  the  U.S.  Government 
coordinate  trials  and  tests  of  new  IPv6  enabled  devices.  It  also  indicated  that  the 
Government  could  support  IPv6  research  into  interoperability  with  existing  IPv4  systems. 

4,  Interoperability 

A  core  capability  of  IP  is  the  interoperability  of  hardware  and  software  that 
interconnects  networks  across  heterogeneous  environments.  Developers  have  created 
dual-stack,  tunneling,  and  translation  mechanisms  to  enable  networks  to  use  either  or 
both  versions  of  IP  to  communicate  with  each  other.  These  mechanisms  are  supposed  to 
eliminate  dependencies  between  vendors  and  networks.  This  will  allow  enterprises  to 
decide  when  to  adopt  IPv6,  if  at  all.  Interoperability  will  not  be  seamless  in  practice. 
The  DoD  will  have  to  address  any  issue  related  to  interoperability  problems  during  the 
transition  from  IPv4  to  IPv6. 

Some  experts  believe  that  differences  in  the  implementation  of  IPv6  could  lead  to 
interoperability  problems  in  some  areas.  [IPv6,  2006]  Incompatibility  may  result  since 
the  protocol  allows  proprietary  functions  to  be  incorporated  in  optional  headers. 
Conformance  testing  needs  to  be  continued  at  organizations  like  JITC.  The  test  beds  and 
activities  like  Moonv6  need  to  be  continued.  If  testing  is  not  continued,  IPv6  products 
developed  in  one  company  might  not  be  compatible  with  those  developed  by  another 
company  under  the  same  general  standards.  In  the  past,  as  well  as  today,  there  have  been 
times  when  a  standard  has  been  met  by  a  company,  but  the  product  may  not  have  actually 
met  the  spirit  of  the  standard’s  intent.  Interoperability  should  be  emphasized  during 
transition  to  minimize  costs  and  efficiency  losses.  Since  standards  include  much  optional 
functionality,  it  is  possible  to  fulfill  the  requirements  of  the  standard  without  meeting  the 
spirit  of  the  intent  of  the  standard. 

Interoperability  can  be  facilitated  by  tunneling  between  IPv6  and  IPv4  networks. 
This  increases  packet  overhead,  but  it  will  not  create  a  problem  for  network  routers; 
however,  it  will  increase  the  processing  time  and  network  overhead  costs.  [IPv6,  2006] 
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The  DoD  can  transition  to  IPv6  at  its  own  pace  with  interoperability  mechanisms.  This 
can  lower  hardware  and  software  costs  and  minimize  the  impact  on  existing  operations. 

The  DoD  must  be  prepared  to  protect  the  wellbeing  of  U.S.  companies  by 
ensuring  that  IPv6  standards  established  or  implemented  by  other  nations  are  open, 
transparent,  and  not  anticompetitive.  [IPv6,  2006]  Concurrent  development  activities  in 
Asia,  Europe,  and  the  U.S.  will  likely  lead  to  interoperability  issues.  Active  companies 
that  are  involved  early  on  in  the  process  will  have  the  opportunity  to  influence  solutions 
and  gain  valuable  experience. 

In  order  to  minimize  adverse  effects  for  users,  the  transition  to  IPv6  should  move 
forward  in  an  observant  and  technology  sensitive  way.  Technical  and  interoperability 
issues  related  to  IPv6  can  be  vetted  through  the  international  standards  development  and 
coordination  bodies. 

The  DoD  has  a  role  to  play  in  the  transition  from  IPv4  to  IPv6:  it  must  influence 
the  market  to  ensure  interoperability.  It  has  resources  that  can  provide  incentives  to  the 
market  place.  Since  the  DoD  is  transitioning  to  IPv6,  industry  is  on  notice  that  it  must 
make  the  transition  if  they  want  to  earn  some  of  the  money  the  DoD  will  spend  over  the 
next  several  years. 

5.  The  DoD’s  Role  in  the  Development  of  IPv6 

The  U.S.  Government  and  its  agencies  will  need  to  coordinate  support  and 
participation  with  industry;  however,  industry  should  take  the  lead  in  developing  the  IPv6 
standards  architecture.  The  same  should  be  applied  to  industry  groups  and  academic 
institutions  with  regard  to  conformance  testing  and  the  development  of  interoperability 
solutions.  As  a  consumer  of  IPv6  products  and  services,  the  DoD  has  an  important  role 
to  play.  It  must  continue  to  evaluate  the  security  and  economic  factors  affecting  adoption 
of  the  new  technology  into  federal  IT  systems. 

The  U.S.  Government  is  a  major  consumer  of  IPv6  products  and  services.  [IPv6, 
2006]  It  can  affect  market  evolution  by  stimulating  private  sector  investment.  The 
timing  of  IPv6  deployment  can  be  influenced  by  Government  purchases.  The  DoD  will 
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create  an  initial  market  of  suffieient  size  to  enable  suppliers  to  progress  and  ereate 
produet  and  serviee  performance  data  for  private  seetor  consumers. 

Various  stakeholders  have  come  to  a  general  eonsensus  that  market  forees  will 
drive  the  private  seetor  transition  from  IPv4  to  IPv6.  The  stakeholders  do  not  believe  that 
there  is  a  signifieant  market  hurdle  for  the  adoption  of  IPv6.  They  believe  that  the 
Federal  Government  should  avoid  aetions  that  would  significantly  interfere  with  market 
forces.  A  comment  was  made  by  a  representative  of  MCI  that  the  deployment  of  IPv6 
oecurred  more  slowly  than  was  anticipated,  but  that  there  was  no  evidenee  of  a  market 
failure  warranting  Government  intervention.  MCI  indicated  that  the  eurrent  pace  of  IPv6 
deployment  refleets  the  normal  weighing  of  benefits  and  costs  that  is  associated  with  any 
teehnology  deployment.  [IPv6,  2006]  Some  experts,  however,  also  emphasized  that  the 
publie  sector  should  foster  development  and  deployment.  They  were  concerned  that  the 
U.S.  was  lagging  behind  in  developing  and  deploying  IPv6  and  that  U.S.  competitiveness 
and  IT  leadership  could  suffer  without  Government  activity. 

6.  DREN  Pilot 

The  DREN  is  the  “DoD's  reeognized  researeh  and  engineering  network.  It  is  a 
robust,  high-capacity,  low-latency  nation-wide  network  that  provides  connectivity 
between  and  among  the  High  Performance  Computing  Modernization  Program  (HPCMP) 
geographically  dispersed  High  Performance  Computing  (HPC)  user  sites,  HPC  Centers, 
and  other  networks.  The  DREN  WAN  eapability  is  provided  under  a  commereial 

contraet.  The  DREN  WAN  service  provider  has  built  DREN  as  a  VPN  based  on  its 

12 

eommereial  infrastructure.” 

The  DoD's  largest  IPv6  and  IPv4  (dual-stack)  network  can  be  researehed  through 
the  DREN  Pilot  project.  The  DREN  has  been  in  operation  since  1992,  but  it  is  not 
Government  owned.  The  DREN  is  provided  as  a  eommereial  service  by  MCI  using 
MPES  on  a  very  high  performance  Backbone  Network  System  (vBNS+).  [Baird,  2004] 


12  The  DREN.  Retrieved  on  19  Aug  2006  from  http://www.hpcmo.hpc.mil/Htdocs/DREN. 
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The  latest  ineamation  of  the  vBNS  was  ereated  in  1995  by  MCI  WorldCom  and 
the  NSF  (National  Science  Foundation).  The  vBNS+  is  a  very  fast  fiber-optic  network 
that  is  one  of  the  test  beds  for  the  Internet2  effort  to  develop  new  protocols  and 
technologies  for  businesses,  education,  Government,  and  private  users.  This  project  is 
proving  the  concept  of  various  transition  mechanisms  from  dual-stack,  IPv6-to-IPv4 
tunneling,  IPv4-to-IPv6  tunneling.  Dual  Stack  Transition  Mechanism  (DSTM),  through 
to  Network  Address  Translation  -  Protocol  Translation  (NAT-PT).  Figure  7.  shows  the 
pyramid  structure  of  the  FIPCMP. 
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Figure  7,  HPCMP  (From:  Baird,  2004) 


13  Smart  Computing®  In  Plain  English.  Retrieved  on  19  August  2006  from 
http://www.smartcomputing.com/editorial/dictionary/detail.asp?guid=&searchtype=&DicID=8005&RefTy 
pe=Dietionary. 

14  Intemet2  is  a  non-profit  eonsortium  which  develops  and  deploys  advanced  network  applications 
and  technologies,  mostly  for  high-speed  data  transfer.  It  is  led  by  207  US  universities  and  partners  from  the 
networking  and  technology  industries  (such  as  AT&T,  Intel,  Sun  Microsystems,  and  Cisco  Systems). 
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7,  Easing  Concerns 

The  DoD  could  provide  information  on  the  current  status  of  IPv6  infrastructure 
and  conformance  testing  requirements.  Some  networks  are  not  testing  and  developing 
IPv6  applications  for  fear  of  issues  like  the  interdependence  between  IPv6  applications 
and  ISP  routing  services.  Access  to  transition  tools  and  better  information  could  help 
ease  the  minds  of  different  organizations.  Some  experts  suggest,  however,  that  markets 
are  pushing  IPv6  development  and  deployment  in  an  appropriate  time  frame.  These 
experts  indicated  that  the  transition  mechanisms  were  designed  to  avoid  the  problem  of 
having  to  “throw  a  switch.”  [IPv6,  2006]  These  experts  do  not  necessarily  agree  that  the 
appropriate  time  frame  includes  the  June  2008  transition  mandate.  Some  wonder  why  the 
DoD  is  pushing  the  transition  on  this  timeline  when  they  expect  that  the  transition  will 
happen  over  a  gradual  period  of  time  at  an  acceptable  pace. 

A  major  issue  arises  over  the  concern  that  users  may  not  demand  IPv6.  Users 
may  not  be  willing  to  pay  for  IPv6-enabled  products,  since  IPv4  works  and  can  also  be 
extended  to  provide  the  same  functionality  as  IPv6. 

C.  RISKS  FROM  THE  SYSTEMS  ENGINEERING  PERSPECTIVE 

1.  Asynchronous  Transfer  Mode  (ATM) 

The  DoD  is  implementing  the  transition  from  IPv4  to  IPv6  for  systems  already 
running  on  IP.  At  the  same  time,  other  networks  are  changing  over  from  ATM  to  IP. 
[Buxbaum,  2006]  Analysts  suggest  that  the  switch  from  ATM  to  IP  has  frequently  been 
overlooked  in  discussions  of  the  IPv6  transition. 

Some  analysts  say  that  it  will  be  better  if  the  DoD  does  not  meet  its  transition 
schedule.  The  DoD  may  want  to  relax  the  schedule  so  that  the  transition  to  IPv6  will 
have  a  rational,  secure  and  cost-effective  result.  [Buxbaum,  2006]  If  the  DoD  scrambles 
against  this  hard  2008  deadline,  shortcuts  may  be  taken  which  might  result  in  irrational 
decisions,  problems  with  security,  and  increased  costs. 

The  transition  involves  upgrading  IPv4  to  IPv6  for  those  systems  already  running 
on  IP.  It  also  involves  switching  over  other  networks  from  ATM  to  IP.  Asynchronous 
Transfer  Mode  was  designed  as  a  bridge  between  synchronous  channel  networking  and 
the  packet-based  networking  characteristic  of  IP  and  frame  relay  communications. 
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[Buxbaum,  2006]  Bit  streams  of  circuit-switched  networks  and  the  packet  streams  of 
packet-switched  networks  are  mapped  by  ATM  onto  a  stream  of  small  fixed  size  cells. 

There  are  tradeoffs  to  consider  when  transitioning  from  ATM  to  IP.  Internet 
Protocol  was  developed  for  maximum  flexibility  and  speed.  Unlike  ATM,  the  IP  packets 
can  vary  in  size  and  more  easily  support  video  streams  and  the  convergence  of  voice,  data 
and  video  communications.  [Buxbaum,  2006]  Security  and  reliability,  however,  were 
technological  layers  added  onto  IPv4,  which  slowed  down  the  movement  of  packets. 
There  is  a  high  level  of  security  and  QoS  associated  with  ATM.  Unfortunately,  ATM 
lacks  the  flexibility  of  IP  communications  because  it  works  with  the  small  fixed  size  cells 
already  mentioned.  [Buxbaum,  2006]  Ralph  Havens,  president  of  Marconi  Federal,  is 
quoted  by  Buxbaum  as  saying. 

In  the  rush  to  simplify  building  applications  for  IP,  people  lost  sight  of  the 
security  and  quality  of  service  that  were  always  givens  in  networks  of  old. 

You  could  actually  trace  circuits  in  their  entirety  from  one  end  to  another, 
and  you  could  guarantee  a  lot  of  security  by  preventing  physical  access  to 
facilities. 

The  issue  here  is  that  ATM  had  the  level  of  security  that  Mr.  Havens  refers  to  in 
the  previous  quote.  The  virtual  circuits  were  managed  end-to-end.  Internet  protocol  uses 
technology  that  allows  packets  to  be  transmitted  using  the  best  route  possible.  Senders 
may  not  know  how  their  packets  get  from  one  end  to  the  other.  The  packets  are  a 
security  risk,  since  they  are  difficult  to  audit  or  constrain.  A  possible  reason  for 
overlooking  ATM  is  due  to  the  fact  that  IPv6  is  the  technological  wave  of  the  future  and 
it  is  cheaper  to  operate  and  maintain  than  ATM.  [Buxbaum,  2006] 

Tom  Nolle  is  the  president  of  a  technology  consulting  and  analysis  company 
called  CIMI.  He  stated  that  IP  networks  will  result  in  a  cost  savings  for  the  DoD.  The 
refresh  and  replacement  cycle  of  equipment  is  involved  with  the  cost  of  transitioning  to 
IPv6.  Once  the  equipment  is  replaced.  Nolle  says  that  running  an  IP  network  instead  of 
“an  ATM  network  of  the  same  capacity”  should  result  in  an  overall  cost  savings  of  “30 
percent  to  40  percent.”  [Buxbaum,  2006]  Mr.  Nolle  made  the  assumption  that 
operational  costs  would  run  about  15  percent  to  25  percent  in  favor  of  IP  if  network 
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administrators  and  operational  personnel  that  brought  up  ATM  networks  were  trained  to 
equal  levels  of  skill  as  those  working  on  IP  networks. 

Transitioning  from  ATM  and  IPv4  to  IPv6  will  be  a  challenge.  The  network 
environments  will  have  increased  complexity,  higher  operating  speeds  and  assured  end- 
to-end  security  regardless  of  network,  application  or  location.  [Guzelian  and  Limoges, 
2006]  Users  were  allowed  to  prioritize  traffic  through  the  built-in  QoS  of  ATM 
networks.  Asynchronous  Transfer  Mode  supports  prioritization  better  than  IPv4; 
however,  IPv6  has  QoS  mechanisms  that  allow  the  deployment  of  advanced  QoS  designs. 
[Guzelian  and  Limoges,  2006]  The  complexity  of  the  network  will  increase  as  IPv6 
improves  IP  network  performance  and  versatility. 

Asynchronous  Transfer  Mode  seems  to  be  overlooked  and  it  may  be  related  to  the 
fact  that  there  is  no  single  policy  established  in  the  DoD.  The  guidance  is  just  that, 
guidance. 

2.  DoD  Ambiguity 

Industry  participants  and  observers  don’t  see  a  single  focused  policy  from  the 
DoD.  There  is  still  no  single  integrated  policy  with  all  of  the  pertinent  dates  of  when 
things  should  happen,  where  issues  will  be  resolved,  and  how  the  transition  will  actually 
be  finalized.  [Buxbaum,  2006]  There  are  a  lot  of  moving  parts,  with  a  lot  of  agencies 
doing  a  lot  to  support  the  transition,  but  they  are  still  missing  the  focused  policy  sought 
by  industry. 

Mike  Guzelian,  director  for  network  security  products  at  the  information 
assurance  division  of  General  Dynamics  C4  Systems,  said  that  it  is  not  possible  to  meet 
the  deadline  since  the  certified  encryptors  for  IPv6  that  they  are  working  on  will  be 
released  around  the  same  time.  He  said  that  the  testing  evolution  will  likely  take  the  DoD 
at  least  a  year.  He  stated  that  the  DoD  will  have  to  update  all  the  switching  and  routing 
equipment  and  that  there  was  not  enough  manpower  to  accomplish  this  all  at  once. 
[Buxbaum,  2006] 
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The  senior  analyst  at  Current  Analysis,  Glen  Hunt,  says  that  rushing  to  implement 
IPv6  is  pointless  sinee  the  applieations  are  not  quite  ready  for  execution.  [Buxbaum, 
2006]  Mr.  Hunt  is  quoted  by  Buxbaum  as  saying. 

To  decree  a  transition  to  IP  is  one  thing,  but  to  actually  see  technology  that 
supports  applications  that  the  military  needs  is  another.  Cisco,  Juniper, 

Alcatel  and  others  are  all  playing  strongly  in  the  IP  router  space  and  are 
doing  a  number  of  IPv6  trials.  But  it’s  not  like  IPv6  will  be  ready 
tomorrow.  It’s  going  to  be  a  mixed  bag  for  some  time  to  come. 

Industry  has  been  working  on  a  way  to  encrypt  ten  gigabit  IP  streams.  [Buxbaum, 
2006]  Hunt  said  that  there  are  vendors  selling  appliances  that  can  convert  ten  gigabit  IP 
traffic  into  ATM.  The  appliance  then  sends  the  ATM  traffic  across  the  network  and 
reconverts  it  back  to  IP  on  the  other  end.  The  ten  gigabit  encryption  development  has 
helped  to  continue  the  transition  to  IP.  Hunt  also  stressed  that  the  market  will  release 
more  reliable  and  intelligent  IP  routers  and  switches  that  will  smooth  the  progress  of  the 
transition. 

Guzelian  said  that  IPv6  beta  version  software  is  being  put  out  onto  networks.  He 
said  that  a  single  machine  can  carry  secret  and  unclassified  traffic  as  a  result  of 
encryption  interfaces  for  personal  computers  (PCs)  and  multilevel  work  stations. 
[Buxbaum,  2006]  A  secret  connection  can  be  made  with  authorized  personnel  and  that 
same  single  user  can  maintain  a  separate  connection  with  coalition  partners  at  the  same 
time. 

The  DoD  may  have  been  the  catalyst  for  the  transition  to  IPv6,  but  industry  will 
have  to  accelerate  the  move  to  IPv6.  Industry  will  have  to  commit  resources  to  IPv6  for 
growth,  performance  and  application  benefits.  Industry  will  have  to  continue  working 
with  the  DoD  to  implement  IPv6  to  develop  the  Net  Centric  Warfare  concept  of 
operations,  to  join  applications,  take  advantage  of  IP  television,  IP  video,  IP  telephony 
and  service-oriented  IP  data  networking. 

3,  Intelligence  Concerns 

The  Information  Sciences  Institute  (ISI)  at  the  University  of  California  prepared 
the  Internet  Protocol  Defense  Advanced  Research  Projects  Agency  (DARPA)  Internet 
Program  Protocol  Specification  in  September  1981  and  called  it  RFC  791.  It  was 
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prepared  for  DARPA  to  speeify  the  DoD  Standard  IP.  It  revised  the  Advanced  Research 
Projects  Agency  (ARP A)  IP  addressing,  error  handling,  option  codes,  and  the  security, 
precedence,  compartments,  and  handling  restriction  features  of  the  IP.  The  DoD  made 
TCP/IP  the  standard  for  all  military  computer  networking  in  1982.  [Hauben,  1998] 
Eventually,  the  computer  industry  helped  popularize  the  protocol,  which  lead  to  increased 
commercial  use. 

The  physical  security  at  network  end  points  dissolved  when  IP  was  opened  to 
commercial  use.  Nolle  indicated  that  the  intelligence  community  is  concerned  with  the 
advertisement  of  false  routes  to  the  network.  The  intelligence  community  may  also  be 
worried  that  IP  encryption  will  be  inadequate  for  intelligence  purposes.  Nolle  said  that 
he  expects  significant  “pushback”  of  the  transition  from  users  and  administrators  of 
intelligence  networks.  [Buxbaum,  2006]  Nolle’s  assumption  that  some  people  in  the 
intelligence  community  do  not  accept  the  level  of  security  offered  by  IP  will  be  addressed 
in  the  flowing  paragraphs. 

Chen  [Chen,  et  ah,  2004]  defined  IPSec  as  a  tunneling  protocol  that  “not  only 
provides  encapsulation/decapsulation  but  encryption/decryption  and  hashing.”  Their 
article,  “Tunnel  Minimization  and  Relay  for  Managing  Virtual  Private  Networks”,  said 
that  “an  IPSec  tunnel  often  fails  to  be  established  due  to  the  management  complexity.” 
Their  work  proposed  the  concept  of  “authority  to  alleviate  the  management  overhead  by 
reducing  the  number  of  tunnels.”  They  described  the  complexity  of  establishing  an  IPSec 
tunnel  between  two  VPN  gateways.  They  indicated  that  administrators  need  to  negotiate 
several  policies,  like  the  Internet  Key  Exchange  (IKE).  They  went  on  to  explain  that 
“administrators  must  specify  the  packets  to  be  transmitted  or  received  through  this  tunnel, 
the  negotiation  mode  (main  or  aggressive)  of  IKE  phase  1,  the  required  sub-protocol 
(ESP  or  AH),  the  encryption  algorithm  (DES  or  3DES),  the  hash  algorithm  (MD5  or 
SHAl),  and  the  PSK  (Pre-Shard  Key).”  Eor  this  reason,  tunnels  are  not  frequently 
established.  They  favored  the  use  of  fewer  tunnels  to  reduce  the  overhead.  Chen,  et  ah, 
restated  that  “packets  that  originally  appear  in  a  reduced  tunnel  are  relayed  to  others, 

AH  is  Authentication  Header;  DES  is  Data  Encryption  Standard;  3DES  is  a  triple  strength  version 
of  DES. 
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violating  the  requisite  for  private  eommunication  through  an  IPSee  tunnel  between  two 
VPN  gateways.”  [Chen,  et  ah,  2004]  This  indieates  that  IPsec  alone  may  not  fill  the 
requirements  desired  by  the  intelligence  community. 

In  the  article  by  Buxbaum,  Nolle  noted  that  security  issues  would  not  have  a  large 
role  in  much  of  the  traffic  carried  on  military  networks.  He  estimated  that  60  percent  to 
70  percent  of  the  traffic  is  similar  to  the  traffic  carried  on  private  sector  networks. 
[Buxbaum,  2006]  Nolle  indicated  that  the  DISA  strategy  to  transition  to  IP  will  impact 
all  military  processes.  He  hypothesized  that  some  specialized  networks  involving 
military  applications  have  not  transitioned  and  that  the  transition,  although  mandated, 
might  be  resisted. 

Security  concerns  are  being  successfully  addressed  through  the  National  Security 
Agency’s  (NSA’s)  commercial  communications  security  (COMSEC)  endorsement 
program.  The  NSA’s  certification  of  wireless  Internet  encryption  technology  is  leading 
to  the  possibility  of  sending  Top  Secret  (TS)  e-mails  from  just  about  anywhere.  A 
modular  IP  encryption  device  will  allow  users  to  send  classified  data  and  voice  messages 
using  unsecured  private  and  public  networks.  [Hawk,  2005] 

SecNet  54™  was  built  by  Harris  Corporation  under  the  NSA’s  COMSEC 
endorsement  program.  The  device  is  undergoing  NSA’s  type-1  encryption  certification 
process  and  an  NSA-certification  of  TS  and  below  is  expected  in  the  Eall  of  2006. 
[Hawk,  2006] 

The  product  overview  [SecNet  54™,  2006]  provided  by  the  Melbourne,  Elorida- 
based  Harris  Corporation,  defines  the  SecNet  54™  device  as: 

The  generic  name  for  Harris  Corporation's  new  family  of  Internet  Protocol 
(IP)  communications  encryption  products,  designed  to  keep  data,  voice, 
and  video  communications  secure.  This  product  is  comprised  of  a 
modular  architecture  with  two  components:  a  Cryptographic  Module 
(CMOD)  that  provides  all  security-critical  functions,  and  an  External 
Module  (XMOD)  that  handles  the  transport  of  encrypted  data  over  specific 
protocols.  Its  modular  design  enables  the  attachment  of  a  variety  of 
XMODs,  allowing  secure  yet  quick  and  easy  utilization  of  standard 
communication  technologies  such  as  wired  802.3  ethernet,  ISDN/PSTN, 
and  wireless  802.11  and  802.16.  With  its  versatility,  small  size,  and  up  to 
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Top  Secret  wireless  and  wired  communications  capabilities,  SecNet  54 

offers  users  a  cost-effective  alternative  to  traditional,  bulky,  in-line 

network  encryption  devices. 

The  DoD  has  made  equipment  replacement  a  part  of  the  transition  plan  to  move  to 
IP.  They  have  built- into  the  plan  a  course  of  action  to  deal  with  purchasing  equipment. 
As  equipment  is  purchased  or  becomes  obsolete,  it  is  replaced  in  the  normal  maintenance 
cycle  with  hardware  and  software  that  is  IPv6  capable. 

4.  Obstacles 

There  are  a  number  of  obstacles  that  face  the  deployment  of  IPv6.  There  is  a  lot 
of  IPv4  compatible  equipment  and  applications  that  are  embedded  in  today’s  systems. 
Many  administrators,  especially  in  the  U.S.,  believe  that  IPv4  is  robust  enough  and 
flexible  enough  to  meet  the  needs  of  the  typical  producer  and  user.  This  comfort  zone 
that  administrators  have  with  IPv4  will  most  likely  hold  back  the  rate  of  migration  to 
IPv6.  [IPv6,  2006]  It  will  take  capital  to  fully  realize  the  potential  end-to-end 
communications  capabilities  of  IPv6.  Additional  capital  will  need  to  be  expended  and 
labor  resources  will  be  required  to  transition  to  the  new  protocol.  The  total  cost  of 
replacing  or  upgrading  all  hardware  and  software  to  be  IPv6  compliant  is  unknown  but 
could  range  in  the  billions  of  dollars. 

Experts  predict  that  legacy  systems  using  IPv4  will  exist  long  after  most  other 
Internet  users  have  migrated  to  IPv6.  [IPv6,  2006]  Interoperability  of  hardware  and 
software  will  be  a  problem  for  enterprises  that  want  to  interconnect  their  networks  across 
mixed  environments.  In  an  enterprise’s  decision  to  adopt  IPv6,  interoperability  will  be  a 
major  consideration. 

Vendors  and  ISPs  are  not  being  pushed  by  the  American  public  at  large  to  deploy 
IPv6  products  and  services.  The  DoD  has  pressed  the  issue  by  mandating  that  its 
agencies  purchase  IPv6  compliant  equipment;  however,  the  demand  for  IPv6  is  still  not 
currently  high  enough  to  warrant  any  kind  of  urgency  from  the  private  sector  in  the  U.S. 
Potential  buyers  are  uncertain  about  products  and  services  regarding  IPv6  benefits.  Users 
are  risk  averse  with  respect  to  potential  innovations.  The  onus  is  placed  on  the 
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organizations  who  first  demonstrate  the  new  teehnology’s  potential.  These  pioneers  ean 
be  discouraged  by  a  costly  and  incomplete  infrastructure,  including  standards. 

5.  Economics 

To  acquire  the  IPv6  capability  in  a  short  period  of  time  will  be  more  expensive 
than  making  the  transition  as  part  of  an  organization’s  normal  upgrade  and  replacement 
cycle.  [IPv6,  2006]  The  IPv6  transition  mechanisms  were  designed  to  allow  IPv4  and 
IPv6  to  exist  together.  Experts  believe  that  ISPs  and  Internet  users  should  replace  IPv4- 
only  hardware  and  software  through  their  normal  product  refresh  cycles.  In  order  to 
transition  to  IPv6,  operational  plans  must  be  created,  security  plans  developed,  and 
training  provided  to  ensure  that  the  transition  occurs  effectively.  If  organizations  replace 
a  majority  of  their  equipment  during  the  normal  refresh  cycle,  most  of  the  costs  related  to 
the  transition  will  be  associated  with  training,  installation,  and  testing  instead  of 
equipment. 

The  DoD  will  likely  incur  greater  costs,  since  it  is  such  a  large  organization.  The 
size  of  those  costs  will  depend  on  the  existing  network  infrastructure  and  operational 
policies.  [IPv6.  2006]  The  modification  of  custom  applications  will  result  in  additional 
costs.  Additional  costs  will  be  generated,  since  the  DoD  will  have  to  connect  to  other 
organizations  using  IPv6. 

Economics  and  security  go  hand  in  hand.  Security  is  required  in  today’s  world, 
and  it  is  expensive. 

6,  Security 

One  of  the  greatest  potential  benefits  of  IPv6  is  security.  The  security  is 
considerably  different  than  what  is  typically  employed  in  today’s  networks.  Designing 
and  developing  new  security  models  will  take  substantial  time  and  expense.  This  new 
and  effective  security  standard  should  benefit  all  existing  and  potential  Internet  users. 
Generally,  experts  agree  that  implementing  IPv6  in  the  near  term  will  involve  an  initial 
time  of  increased  security  vulnerability.  [IPv6,  2006]  New  threats  posed  by  a  dual 
standard  environment  will  require  additional  resources.  The  IPv6  protocol  has  new 
capabilities,  such  as  auto-configuration,  but  new  threats  and  vulnerabilities  will  emerge 
and  need  to  be  addressed  to  avoid  abuse. 
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Attackers  will  undoubtedly  give  IPv6  more  attention  as  IPv6  becomes  more 
prevalent.  Many  seeurity  issues  will  likely  arise  and  will  need  to  be  addressed.  The  DoD 
is  working  on  seeurity  plans  and  polieies  for  dealing  with  IPv6  traffie.  The  DoD  will 
need  to  eontinue  to  devote  resourees  to  test  and  evaluate  its  capabilities.  The  impaet  of 
transition  mechanisms  on  security  architectures  will  need  continuous  evaluation.  The 
DoD  needs  to  ensure  the  security  and  stability  of  networks  during  the  transition  and 
establish  the  best  praetices  for  new  seeurity  policies  and  management  meehanisms. 

The  U.S.  Department  of  Commerce  Technical  and  Economic  Assessment  of  IPv6 
indicated  that  more  seeurity  holes  will  be  found  in  IPv6  and  its  related  transition 
meehanisms  than  in  IPv4.  [IPv6,  2006]  It  stated  that  in  the  first  few  years  of  significant 
IPv6  use,  their  will  be  no  better  security  than  what  can  be  realized  with  IPv4-only 
networks.  The  increased  use  of  end-to-end  seeurity  mechanisms  may  improve  security. 

A  way  to  provide  security  to  a  network  is  through  the  use  of  firewalls.  The  use  of 
firewalls  at  the  perimeter  will  reinforce  the  use  of  firewalls  at  the  core  of  the  network. 
This  will  help  to  protect  the  core  and  support  the  transition  through  an  ineremental 
implementation.  Most  enterprises  consist  of  a  limited  number  of  intereonnection  points 
where  network  links  are  partitioned  into  external  segments,  internal  private  segments,  and 
internal  public  segments.  Security  devices  are  plaeed  at  the  intersection  of  each  of 
these  segments.  They  enforee  site -wide  seeurity  policies,  provide  security  services,  and 
monitor  traffie  for  seeurity  events.  [IPv6,  2006]  Virtual  private  networks  may  be  used  to 
seeurely  connect  one  trusted  network  to  another,  given  the  implementation  includes  data 
eneryption,  sueh  as  that  provided  by  IPSec  feature  of  IPv6.  Network  Address  Translation 
devices  allow  the  private  segments  of  the  enelave  to  use  private  addressing.  Perimeter 
based  security  models  provide  an  advantage  in  that  they  foeus  on  site  seeurity  definition, 
management,  enforcement,  and  auditing  at  certain  points  in  the  network.  These  perimeter 
seeurity  points  are  under  the  control  of  enterprise  seeurity  organizations.  These  assets  are 


16  External  segments  need  network  layer  access  outside  the  enterprise.  Private  segments  do  not 
require  access  to  hosts  in  other  enterprises  or  the  internet  at  large;  however,  some  private  segments  may 
need  access  to  a  limited  set  of  outside  services  (i.e.,  E-mail,  FTP,  netnews,  or  remote  login).  Retrieved 
from  RFC  1918  on  18  August  2006. 
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highly  maintained  and  monitored  in  enterprise  network  infrastructures.  Audit  functions 
that  are  centralized  allow  for  easy  integration  with  equipment.  [IPv6,  2006] 

The  security  at  the  perimeter  is  important.  But  it  is  also  important  to  ensure  that 
mechanisms  at  the  core  and  periphery  can  interoperate. 

D,  SUMMARY 

Chapter  IV  provided  a  look  at  the  issues  related  to  the  early  stages  of  transitioning 
to  IPv6  in  the  United  States.  It  provided  an  approach  to  trace  the  progress  of  the 
transition.  The  Navy’s  transition  was  discussed  to  provide  a  possible  solution  for  other 
agencies.  It  also  presented  a  few  issues  that  may  need  to  be  further  researched  to  ensure 
they  are  included  in  the  transition.  This  chapter  reviewed  the  position  of  industry  experts 
and  most  believed  there  was  no  rush  to  transition  to  IPv6. 

E,  CONCLUSION 

The  benefits  and  costs  of  potential  market  applications  are  uncertain.  There  exists 
a  consensus  among  experts  that  the  long  term  adoption  of  IPv6  is  important.  The  current 
market  driven  adoption  of  IPv6  by  the  private  sector  is  moving  at  a  practical  pace.  An 
efficient  migration  will  occur  at  an  acceptable  cost  as  a  result  of  transition  mechanisms; 
however,  other  countries  are  adopting  IPv6.  This  could  change  the  situation  and  the 
complexity  of  the  infrastructure  necessary  to  effect  the  transition  from  IPv4  to  IPv6.  It  is 
likely  that  the  transition  will  require  additional  support.  Technology  and  economic  policy 
issues  need  to  be  examined  regularly  in  order  to  determine  what  support  may  be  needed 
for  the  growing  IPv6  activities  by  industry,  the  federal,  state,  and  local  governments. 

The  DoD  should  consider  moving  forward  with  the  transition  but  not  fixate  on  the 
2008  deadline.  The  DoD  can  concentrate  on  a  smooth  transition  as  systems  are  replaced 
through  the  normal  technical  refresh  cycle. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A,  INTRODUCTION 

This  thesis  examined  the  DoD  transition  plan  from  IPv4  to  IPv6.  Based  on  the 
DoD’s  Transition  Plan  and  publie  information  about  IPv4  and  IPv6,  the  movement  from 
IPv4  to  IPv6  will  be  influeneed  by  the  Government  and  private  industry  in  the  United 
States,  as  well  as  the  international  eommunity.  This  is  neeessary  sinee  the  United  States 
will  take  a  “back  seat”  in  the  global  IT  arena  should  it  transition  at  its  own  pace  rather 
than  keeping  up  with  the  transition  taking  place  in  Europe  and  Asia.  In  the  United  States, 
the  DoD  has  shown  a  significant  amount  of  initiative  in  the  transition  to  IPV6;  however, 
globally,  the  United  States  is  behind  Europe  and  even  further  behind  Asia.  Chapter  3 
described  how  every  service  provider  in  Japan  uses  the  IPv6  production  network  and 
South  Korea  is  working  with  Europe  to  develop  applications  and  services  for  IPv6.  The 
same  cannot  be  said  for  the  U.S. 

Internet  Protocol  version  4  is  a  protocol  that  has  been  in  use  for  over  20  years  and 
it  allows  computers  to  communicate  across  diverse  infrastructures.  The  Internet,  and 
most  other  data  networks,  uses  IPv4.  In  the  I980’s,  the  number  one  bandwidth  usage  was 
related  to  electronic  mail.  In  the  I990’s,  the  number  one  usage  moved  over  to  the 
emerging  world-wide -web  access.  At  the  forefront  of  the  development  of  IPv6  was  the 
proliferation  of  user  devices  and  successful  high  utility  applications.  Eor  example,  IPv4 
address  space  became  too  limited  to  keep  up  with  the  explosive  growth  so  efforts  were 
initiated  to  mitigate  that  constraint.  Those  efforts  resulted  in  the  establishment  of  IPv6. 
Today,  the  number  one  usage  is  peer-to-peer  (P2P)  file  sharing.  Tomorrow,  the  DoD  will 
use  many  mobile  P2P  Services.  [Baird,  2004]  The  transition  to  IPv6  is  necessary  to  keep 
up  with  the  technological  world. 

Internet  protocols  provide  the  set  of  rules  that  define  how  computers  can 
communicate  with  each  other  across  heterogeneous  network  infrastructures.  They  use 
individually  routed  packets  rather  than  dedicated,  switched  circuits.  Most  online  systems 
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now  use  IPv4  as  the  network  layer  protoeol  whieh  is  responsible  for  forwarding  these 
paekets  between  routers  and  other  network  deviees,  but  the  move  toward  IPv6  is  well 
under  way. 

Request  for  Comment  2460  deseribes  how  IPv6  is  a  new  version  of  the  IP  and 
that  it  was  designed  as  the  sueeessor  to  IPv4.  The  ehanges  from  IPv4  to  IPv6  are  listed  in 
RFC  2460  and  fall  into  the  primary  following  eategories: 

1.  Expanded  Addressing  Capabilities: 

Request  for  Comment  2460  identities  that  IPv6  will  have  a  four-fold  inerease  in 
network  address  spaee  that  will  provide  for  greater  flexibility  in  network  hierarehieal 
design  as  well  as  implementation  of  autonomous  host  eonfiguration.  Internet  Protoeol 
version  6  has  the  ability  and  flexibility  to  meet  the  growth  requirements  of  multieast 
routing  by  adding  a  “seope”  field  to  multieast  addresses.  The  new  type  of  address  is 
ealled  an  “anyeast  address”  and  it  is  used  to  send  a  paeket  to  any  one  of  a  group  of  nodes. 

2.  Header  Format  Simplification: 

According  to  RFC  2460,  IPv6  simplifies  the  header  fields.  It  reduced  the 
common-case  processing  cost  of  packet  handling  and  limited  the  bandwidth  cost  of  the 
IPv6  header. 

3.  Improved  Support  for  Extensions  and  Options: 

More  efficient  forwarding  results  from  the  way  IP  header  options  are  encoded. 
The  encoding  changes  also  allow  for  less  rigorous  boundaries  on  the  length  of  options  as 
wells  as  a  greater  flexibility  for  initiating  new  alternatives  in  the  future. 

4.  Flow  Labeling  Capability: 

The  labeling  of  packets  belonging  to  particular  traffic  “flows”  is  a  new  capability 
identified  by  RFC  2460.  The  sender  can  request  special  handling  for  services  such  as 
non-default  QoS  or  “real-time”  service. 

5.  Authentication  and  Privacy  Capabilities: 

The  final  primary  category  of  changes  brought  by  IPv6  is  that  authentication,  data 
integrity,  and  data  confidentiality  are  supported  by  extensions  specified  for  IPv6. 

The  need  to  consistently  assess  the  transition  from  IPv4  to  IPv6  and  its  impact  on 
the  DoD’s  computer  architecture  will  continue  well  into  the  future.  The  challenge  is  to 
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allow  organizations  the  autonomy  to  go  after  the  best  available  assets  for  the  DoD 
without  strictly  defining  how  to  accomplish  the  task.  The  DoD  must  transition  to  IPv6, 
but  it  must  also  measure  the  cost  incurred  to  ensure  the  transition  is  smooth  but  not 
strangled  by  an  arbitrary  deadline  currently  set  for  2008.  The  goal  is  to  have  agency 
backbones  IPv6  capable  by  2008,  so  that  they  are  ready  to  accommodate  IPv6  traffic; 
however,  they  will  not  necessarily  have  to  pass  IPv6  packets. 

B,  ANSWERS  TO  RESEARCH  QUESTION 

This  section  discusses  the  research  questions  posed  for  this  thesis  in  Chapter  I. 

1,  Primary  Research  Question 

What  is  the  value  of  transitioning  to  IPv6? 

The  DoD  will  reap  the  rewards  for  starting  the  transition  to  IPv6  before  the  rest  of 
the  U.S.  The  architectural  structure  of  the  network  is  changing  because  of  the  new 
features  in  IPv6  and  this  makes  the  transition  very  complex. 

Transitioning  from  IPv4  to  IPv6  will  prove  to  be  a  difficult  challenge  for  the  DoD 
and  its  networking  personnel.  The  transition  is  going  to  happen,  so  the  networking 
personnel  are  preparing  for  the  change.  It  appears  that  the  biggest  challenge  to  IPv6  is 
that  IPv4  networks  administrators  are  satisfied  with  the  inner  workings  of  IPv4.  After  all, 
the  IPv4  network  provides  the  same  capability  as  IPv6  through  the  use  of  extensions. 
The  major  difference  is  that  IPv6  has  the  IPv4  extended  capabilities  built-in  rather  than 
added  on,  after  the  fact.  With  this  information,  there  appears  to  be  no  rush  by  the 
American  public  to  migrate  to  IPv6.  The  DoD  could  not  afford  to  remain  status  quo  with 
regard  to  IPv4.  If  the  DoD  had  not  mandated  the  transition,  it  may  well  have  been  at  risk 
of  being  pushed  into  IPv6  in  a  relatively  short  timeframe. 

Internet  Protocol  version  6  impacts  the  network  addressing  and  routing 
mechanisms.  All  devices  on  the  network  will  have  a  new  address  once  the  transition  is 
completed.  Proper  planning  has  made  IPv6  backward  compatible  with  existing  IPv4 
installations.  Tunneling  or  transition  mechanisms  will  allow  IPv4  and  IPv6  to  run  at  the 
same  time  on  the  same  network. 
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The  reports  being  filed  by  DoD  organizations  will  provide  the  leadership  the 
assurance  that  IPv6  is  providing  a  strategic  value.  They  will  also  provide  the  status  of  the 
transition  so  that  progress  can  be  made  available  for  future  decisions.  The  DoD  made  a 
good  start  by  creating  a  transition  office  and  centralizing  the  transition  at  DISA.  The 
Services  have  also  moved  forward  by  creating  their  own  transition  offices. 

The  DREN  pilot  is  a  resource  that  will  aid  with  the  transition  planning  and 
implementation  activities.  This  will  result  in  a  budgetary  savings  when  compared  to  the 
consequence  of  ignoring  the  transition  requirements.  The  transition  has  been  sponsored 
by  the  DoD.  The  policy  has  been  developed,  but  it  does  remain  flexible  so  that 
adjustments  to  the  schedule  can  be  made.  Since  the  transition  has  a  high  priority  for  the 
DoD,  obtaining  resources  may  be  unproblematic  when  compared  to  traditional  funding 
battles.  The  DoD  has  already  made  a  valuable  step  to  the  transition  by  mandating  that  all 
equipment  purchases  be  IPv6  capable.  In  addition  to  this  mandate,  the  term  “IPv6 
capable”  was  defined  by  the  DoD  Transition  Office  to  provide  an  end  state  to  network 
administrators.  The  DoD  must  continue  to  expend  resources  on  solving  IPv6  problems 
and  migrate  away  from  solving  IPv4  problems.  Research  and  development  is  being 
conducted  with  VoIP,  convergence,  QoS,  and  other  issues  related  to  IPv6. 

Internet  Protocol  version  4  will  coexist  with  IPv6  for  several  years.  There  is 
every  reason  to  believe  that  the  transition  can  overlap  with  normal  technology  upgrades. 
It  is  just  a  matter  of  time  before  the  DoD  is  IPv6  capable  end-to-end.  At  that  time,  the 
DoD  may  take  full  advantage  the  new  IPv6  features. 

2.  Subsidiary  Research  Question  #1 

How  will  the  cost  of  the  new  protocol  be  assessed  in  terms  of  complexity  and 
performance? 

The  research  completed  in  this  thesis  suggests  that  the  transition  will  continue  to 
be  complex  and  that  the  DoD  will  need  to  continue  to  push  headlong  into  moving  to 
IPv6.  Beginning  with  an  inventory  of  DoD  equipment  that  is,  or  is  not,  IPv6  compatible 
is  a  good  start  to  the  overall  process.  The  new  protocol  will  not  only  need  new 
equipment,  but  it  will  also  require  training  and  education  for  anyone  involved  with 

communication  and  Internet  protocols.  The  DoD  will  need  to  expand  it’s  testing  and 
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conformance  beyond  JITC  down  several  subordinate  layers  of  the  DoD.  The  testing 
should  start  to  expand  to  begin  to  understand  the  full  requirement  to  transition  to  an  IPv6 
environment  that  will  co-exist  with  IPv4. 

3.  Subsidiary  Research  Question  #2 

How  will  communication  equipment  be  considered  within  the  DoD? 

The  Department  of  Defense  is  currently  seen  as  the  leader  in  the  United  States  for 
its  advances  toward  transitioning  to  IPv6.  Communication  is  always  expensive  and  the 
refresh  cycle  associated  with  IPv6  compatible  equipment  is  a  means  that  will  allow  the 
DoD  to  catch  up  to  the  rest  of  the  world  with  regard  to  transitioning  to  IPv6.  There  will 
be  no  support  for  IPv6  applications  or  services,  only  the  transport  mechanisms  will  be  in 
place  by  2008.  The  developers  of  IPv6  made  IPv6  backward  compatible  with  IPv4  via 
interoperability  mechanisms.  Since  only  the  backbone  is  transitioning  in  2008,  there  will 
only  be  support  for  the  NIPRNet  and  Teleport, 

4,  Subsidiary  Research  Question  #3 

Is  it  best  to  transition  from  the  periphery  or  the  core? 

The  Defense  Information  Systems  Agency  is  implementing  IPv6  over  a  DISN 
core  Ipv4  backbone.  The  Ipv6  routing  architecture  /  policy  will  remain  the  same  as  the 
DISN  core  Ipv4. 

The  potential  security  risks  to  Ipv6  will  take  time  to  uncover.  Programmers  that 
currently  spend  time  attacking  Ipv4  systems  will  undoubtedly  begin  to  attack  Ipv6  on  a 
regular  basis.  When  the  core  is  Ipv6  capable,  theoretically,  attacks  via  covert  channels 
should  be  held  off  by  the  periphery.  However,  hijacking  the  core  and  preventing  data 
flow  to/from  the  user  community  in  the  periphery  can  cause  a  denial  of  service.  Another 
threat  is  the  maintenance  and  refresh  cycle.  The  system  will  continue  to  be  vulnerable  as 
long  as  a  core  or  periphery  device  is  still  working  off  Ipv4.  Services  are  provided  at  the 


17  Teleport:  “The  system  will  integrate,  manage,  and  eontrol  a  variety  of  eommunieations  interfaees 
between  the  Defense  Information  System  Network  (DISN)  terrestrial  and  taetieal  satellite  eommunieations 
(SATCOM)  assets  at  a  single  point  of  presenee.”  Retrieved  on  27  Aug  2006  from 
http://www.disa.mil/main/prodsol/teleport.html 
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periphery,  because  the  core  primarily  functions  to  forward  traffic.  The  IPSec 
functionality  is  a  periphery  service  and  it  is  done  at  the  first  and  last  encountered  Ipv6 
device. 

The  current  initiatives  by  the  Navy  indicate  that  transitioning  from  the  core  can  be 
done  as  long  as  the  necessary  precautions  are  taken  to  avoid  security  risks.  The  problem 
is  that  there  is  no  way  to  tell  where  security  problems  will  arise  until  Ipv6  is  more 
prevalent.  Should  the  transition  happen  from  the  core  to  the  periphery,  the  DoD  will 
invite  attackers  to  get  directly  into  it’s  core  network.  If  the  transition  begins  from  the 
periphery,  this  will  allow  the  DoD  to  continue  to  test  for  security  problems  in  Ipv6 
without  a  significant  threat  to  its  core  network.  At  the  same  time,  research  can  be  done  to 
track  the  progress  of  attackers  on  the  new  protocol.  As  the  attacks  are  identified,  the 
DoD  can  protect  itself  against  those  known  attacks  and  prevent  them  from  getting  to  the 
core.  As  the  risk  of  significant  damage  to  the  periphery  is  reduced,  the  core  can  then 
begin  its  transition  to  Ipv6. 

This  analysis  indicates  that  there  is  no  one  correct  answer  with  regard  to 
transitioning  from  the  core  or  the  periphery.  Both  can  be  hazardous  to  the  system.  At  the 
very  least,  the  DoD  should  take  an  evolutionary  approach  to  the  transition.  The  transition 
should  be  made  by  starting  with  areas  that  will  have  the  least  impact  on  the  system  should 
it  be  attacked. 

Transitioning  from  the  core  would  undoubtedly  have  the  highest  risk  of  failure. 
This  approach  could  result  in  a  single  point  of  failure  where  an  attacker  might  only  need 
to  get  past  one  router.  Attack  techniques  can  be  tracked  and  mitigated  at  the  periphery 
prior  to  the  transition  of  the  core.  This  would  keep  an  attacker  from  getting  past  a  router 
today  that  might  have  been  thwarted  by  a  security  upgrade  tomorrow.  The  system  may 
be  able  to  withstand  an  attack  to  a  part  of  its  periphery,  but  the  same  cannot  be  said  for 
the  core. 
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5,  Subsidiary  Research  Question  #4 

What  risks  are  involved  with  the  transition? 

Software,  hardware,  teehnology,  eost,  sehedule,  seeurity,  and  people  are  all  risks 
to  the  transition.  Vendors  in  the  United  States  will  need  to  continue  to  develop  software 
and  hardware  for  IPv6.  The  DoD  will  also  need  to  continue  to  purchase  IPv6  compatible 
equipment  so  that  companies  will  be  motivated  to  not  only  produce  quality  products,  but 
to  also  innovate  and  create  new  technologies  to  help  support  the  warfighter.  The  United 
States  needs  to  be  concerned  that  it  is  falling  behind  the  rest  of  the  world  in  the  transition 
to  IPv6.  It  is  possible  that  individual  home  users  will  not  be  affected  by  the  transition 
since  ISPs  will  eventually  provide  their  customers  with  a  dual-stack  transition 
mechanism.  The  DoD  plans  to  move  beyond  the  dual-stack  environment  to  a  native  IPv6 
environment.  Since  the  DoD  has  been  directed  to  buy  IPv6  capable  equipment,  it  can  be 
safely  assumed  that  private  ISPs  will  not  be  a  reliable  model  for  the  DoD  to  follow  with 
regard  to  transitioning  the  core.  The  ISPs  can’t  control  the  transition  of  the  private  user, 
while  the  DoD  can  generate  a  directive  that  requires  users  to  make  the  transition. 

The  scheduled  transition  is  for  June  2008;  it  is  a  certainty  that  the  schedule  will 
slip  and  prolong  the  DoD’s  risk  associated  with  IPv4  traffic  on  the  IPv6  network. 

6,  Subsidiary  Research  Question  #5 

Has  the  DoD  declared  its  requirement  for  IPv6  products? 

The  DoD  has  not  strictly  declared  it  requirements,  but  it  has  inventoried  its  IPv6 
compliant  equipment.  Once  the  technologies  materialize,  organizations  will  be  able  to 
enable  IPv6  capable  hardware.  As  long  as  interoperability  is  available  and  the  market  is 
big  enough,  users  will  likely  adopt  IPv6  hardware  and  software  products. 

7,  Subsidiary  Research  Question  #6 

Have  vendors  invented  new  products  or  will  the  DoD  first  have  to  specify  the 
requirement? 

Internet  Protocol  version  6  products  are  being  developed  by  U.S.  and  foreign 
countries.  Vendors  in  the  U.S.  could  reduce  their  costs  by  developing  and  deploying 
products  that  already  have  solutions  for  issues  that  were  resolved  in  foreign  countries. 
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The  DoD  should  continue  to  realize  the  benefits  of  foreign  IPv6  deployment  as  long  as  its 
IPv4  networks  and  applications  can  connect  to  IPv6  networks  and  applications. 

8,  Subsidiary  Research  Question  #7 

What  is  the  DoD  policy  with  regard  to  opening  the  core  to  new  technology? 

The  DoD  is  working  on  a  strategy  that  allows  the  core  to  be  touched  by  IPv6  as 
long  as  all  appropriate  security  measures  have  been  taken.  There  are  varying  levels  of 
IPv6  readiness  in  products.  Most  networking  equipment  is  advertised  as  ‘TPv6-ready”  or 
‘TPv6-capable,”  but  network  engineers  must  be  aware  of  the  differences  between  the 
basic  functionality  of  one  device  and  the  advanced  IPv6  functionality  of  another  device. 

The  DoD  is  not  currently  working  toward  a  native  IPv6  environment,  at  any 
command,  which  would  require  all  IPv4  to  IPv6  transition  mechanisms  to  be  eliminated. 
The  DoD  will  continue  its  transition  to  IPv6,  but  it  will  be  saddled  with  both  transition 
mechanisms  and  tunneling  for  the  foreseeable  future. 

C.  AREAS  FOR  FURTHER  RESEARCH 

The  DoD  will  be  looking  to  IPv6  to  provide  mobility  to  its  force.  This  should  be 
a  driving  factor  behind  IPv6  technologies  in  the  DoD. 

Continuing  to  run  IPv4  may  become  impractical  or  more  costly  than  transitioning 
to  IPv6.  The  inventories  submitted  by  agencies  within  the  DoD  can  be  reviewed  and 
analyzed  to  determine  whether  or  not  organizations  will  want  to  transition  to  IPv6  or 
must  be  forced  to  do  so  as  a  result  of  a  directive  from  higher  headquarters. 

A  study  of  IPv6  in  the  U.S.  can  be  conducted  on  both  independent  research  and 
the  collaboration  of  ideas  with  private  stakeholders.  The  study  should  include  the  DoD’s 
communications  networks  and  its  ability  to  help  U.S.  companies  compete  in  the  global 
market  for  IPv6  products,  networks,  and  services.  It  is  important  to  disseminate 
information  inside  and  outside  of  the  DoD  about  the  use  of  IPv6. 

Testing  of  IPv6’s  interoperability  with  existing  IPv4  systems  can  be  further 
researched  as  well  as  techniques  to  improve  the  performance  and  efficiency  of  IPv6  VoIP 
and  mobile  IPv6  routing.  Continuous  testing  will  need  to  be  conducted  for  security  in 
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dual-stack  environments,  intrusion  detection  techniques  for  IPv6,  performance  in  dual 
IPv4/IPv6  environments.  Public  Key  Infrastructure  scalability,  and  secure  Border 
Gateway  Protoeol  (BGP). 

The  transition  for  planning  and  exeeution  is  based  on  three  Milestone  Objeetives 
found  in  the  DoD  Transition  Plan.  The  DoD  is  eurrently  in  Milestone  Objeetive  1 
(MOl).  Milestone  Objective  2  (M02)  is  seheduled  to  start  on  1  October  2006.  There 
will  be  "live"  IPv6  paekets  on  the  GIG  by  the  time  M02  begins;  however,  it  will  be 
eonfined  to  DoD  networks  and  between  pilot  enelaves.  The  different  milestones  ean  be 
studied  for  their  eompleteness  and  timeliness. 

Only  the  DoD  baekbone  is  transitioning  on  30  June  2008.  The  baekbone 
transition  eonsists  of  the  NIPRNet  and  Teleport.  There  will  be  no  support  for  IPv6 
applieations  or  serviees,  only  the  transport  meehanism.  Future  researeh  of  this  subjeet 
ean  be  done  by  revisiting  the  DISA  IPv6  Implementation  Plan.  Additional  information 
ean  also  be  obtained  from  the  DoD  IPv6  Transition  Offiee. 

Seeurity  ean  possibly  be  the  subjeet  for  an  entire  researeh  project.  The  NIST  will 
publish  a  standards  profile  in  November  2006  and  teehnieal  guidance  that  focuses 
extensively  on  eyberseeurity  in  early  2007. 

D,  CONCLUSIONS 

If  it  weren’t  for  the  DoD  mandate  to  transition  to  IPv6  by  30  June  2008,  it  is 
likely  that  the  United  States  would  move  to  IPv6  mueh  later  than  Europe  and  Asia.  This 
is  apparent  beeause  service  providers  are  eurrently  using  the  IPv6  network  in  eountries 
other  than  the  U.S.  Many  publieations  indieate  that  administrators  in  the  U.S.  believe  the 
extensions  provided  by  IPv4  are  just  as  good  as  the  built-in  features  of  IPv6.  The  DoD  is 
ereating  a  market  for  IPv6  equipment  and  software  in  the  U.S.,  as  the  mandate  included  a 
requirement  for  the  aequisition  of  all  new  eomputer  equipment  to  be  IPv6  eapable.  As  a 
result,  eompanies  sueh  as  CISCO  have  been  selling  IPv6  eompatible  equipment  for  a 
eouple  of  years.  The  DoD’s  market  share  of  the  U.S.  eomponent  of  the  Internet  is  not  as 
influential  over  the  status  of  the  Internet  as  was  DoD’s  influenee  over  the  development 
and  advancement  of  the  networks  that  ultimately  eulminated  in  the  Internet.  Thus,  the 

DoD  must  eontinue  to  aggressively  eoordinate  and  support  the  development  of  IPv6 
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standards,  protocols,  and  conformance  if  it  holds  the  transition  to  be  one  of  its  eore 
interests.  It  must  be  an  active  participant  in  identifying  and  facilitating  solutions  for 
technological  and  interoperability  issues.  It  is  in  the  best  interest  of  the  DoD  that  it 
eontinue  to  be  a  major  faetor  in  stimulating  the  adoption  of  IPv6  by  being  a  major 
eonsumer  of  IPv6  produets  and  serviees. 

Various  publieations  and  interviews  were  used  to  eompile  the  qualitative  data 
eollected  and  analyzed  in  this  thesis.  The  eonsensus  of  various  experts  overwhelmingly 
indicated  that  the  U.S.  as  a  whole  needs  to  transition  to  IPv6  in  order  to  maintain  its  place 
at  the  forefront  of  teehnology  innovation.  There  is  some  debate,  however,  as  to  the  most 
benefieial  timeline.  Some  believe  that  the  DoD’s  push  is  neeessary  to  lead  the  eharge  to 
IPv6,  others  believe  that  IPv6  will  make  the  transition  through  a  more  natural 
progression.  The  global  view  of  IPv6  indieates  that  if  the  U.S.  does  not  transition  with 
the  rest  of  the  world,  it  eould  be  left  with  transition  mechanisms  and  security  holes, 
leaving  the  world  to  look  inside  its  network.  The  idea  that  the  extended  seeurity  features 
of  IPv4  are  just  as  good  as  the  built-in  seeurity  of  IPv6  may  be  valid,  but  the  DoD  should 
eontinue  it’s  move  to  IPv6. 

An  advisory  of  security  issues  concerning  IPv6  was  issued  by  the  Department  of 
Homeland  Seeurity,  aeeording  to  0MB  memorandum  05-22.  It  appears  that  the  DoD 
wants  to  avoid  possible  seeurity  issues,  sinee  it  will  be  a  part  of  the  IPv6  network,  be  it  by 
tunneling  or  using  transition  meehanisms.  In  June  2008,  all  ageneies’  network  baekbones 
must  be  using  IPv6  and  ageney  networks  must  interfaee  with  this  infrastrueture. 
Guidanee  was  published  to  ensure  an  orderly  and  secure  transition  from  IPv4  to  IPv6, 
beeause  the  Internet  Protoeol  is  eore  to  the  ageney’s  IT  infrastrueture. 

The  Federal  transition  to  IPv6  is  progressing  slowly,  but  the  momentum  may  be 
pieking  up.  Most  ageneies  have  submitted  their  final  offieial  transitional  reports  to  0MB, 
but  the  networks  must  still  be  upgraded.  Guidanee  is  being  prepared  for  ageneies  to 
migrate  their  network  baekbones  to  the  new  Internet  Protoeol. 

The  eommands  should  be  able  to  meet  the  IPv6  requirement  through  routine 
upgrades  and  teehnology  refreshes.  Additional  resourees  may  be  needed  for  ongoing 
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planning,  training,  labor,  the  management  of  the  transition  and  the  resulting  dual-stack 
network  implementation.  Many  agencies  do  not  understand  how  they  will  be  using  the 
new  protocol;  therefore,  asking  for  and  receiving  funding  may  prove  to  be  difficult. 

The  DoD  has  an  IPv6  certification  program  to  help  test  for  compliance,  but  the 
move  to  a  fully  functional,  native  IPv6  network  will  not  be  available  by  June  2008. 
Project  planners  are  testing  these  new  technologies  that  will  be  used  in  the  next  10  years. 

An  important  DoD  resource  for  research  and  engineering  is  the  DREN.  The 
DREN  provides  a  strong  interconnectivity  with  other  major  networks  and  high 
performance  test  beds.  It  is  a  resource  that  enables  wider  user  of  IPv6  by  the  DoD 
research  community  and  should  be  leveraged  accordingly. 

E.  RECOMMENDATIONS 

1.  The  DoD  Should  Continue  Its  Transition  to  IPv6  Without  a 
Deadline  as  Close  as  June  2008 

As  industry  develops  IPv6  compatible  equipment,  it  will  undoubtedly  get  better 
and  more  efficient  and  cost  effective.  Time  will  also  allow  those  who  attack  computer 
systems  to  reveal  their  treachery.  In  the  meantime,  the  DoD  will  be  able  to  adjust  its 
timeline  for  the  acquisition  of  equipment  as  well  as  policies  regarding  its  computer 
infrastructure.  Delaying  the  acquisition  of  equipment  will  allow  the  DoD  to  take 
advantage  of  more  secure  equipment  and  software  as  they  become  available.  The  time 
will  also  allow  for  more  in-depth  testing  for  conformance.  Testing  and  acquisition  should 
continue,  however,  the  transition  deadline  could  easily  be  pushed  back  a  couple,  if  not  a 
few,  years. 

2.  The  DoD  Should  Expand  Its  Test  Bed 

Currently,  the  test  beds  are  limited  to  a  few  specific  sites  in  the  DoD.  This  testing 
should  be  shared  with  several  commands,  to  include  the  necessary  equipment  to  conduct 
long  distance  analysis.  This  will  require  that  the  DoD  invest  in  specialists  that  work  in 
the  IP  field.  These  specialists  will  need  to  be  at  each  test  site  and  will  need  to  be 
employed  for  the  next  three  to  five  years. 
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3,  The  DoD  Should  Develop  Formal  IPv6  Training  and  Education. 

The  specialized  skills  taught  to  military  members  in  the  computer  science 
specialty  will  need  to  include  knowledge  about  IPv6.  This  training  would  need  to  be 
inserted  into  the  curriculum  while  the  students  are  in  the  accession  pipeline.  This  training 
will  also  need  to  be  presented  in  the  advanced  courses.  They  will  need  to  be  experienced 
with  both  IPv4  and  IPv6  so  that  they  will  be  conversant  in  both  protocols.  If  they  are  not 
formally  trained  in  the  schoolhouse,  they  will  have  to  learn  about  IPv6  on  the  job.  This 
may  not  be  the  best  place  to  learn  about  IPv6,  since  it  is  the  inexperienced  that  often  get 
taken  advantage  of  by  more  experienced  attackers. 

4,  The  DoD  Should  Increase  Its  Participation  in  Local,  Regional, 
National,  and  International  Meetings  Designed  to  Develop  the 
Next  Generation  Protocol, 

This  thesis  found  that,  relatively  speaking,  there  are  only  a  handful  of  DoD 
personnel  participating  in  conferences  related  to  IPv6.  There  have  been  DoD  sponsored 
conferences,  but  military  participation  should  be  increased  beyond  its  current  level. 

5.  The  DoD  Should  Expand  Its  Testing  Influence  and  Participation, 

The  DoD  could  expand  its  support  of  standards  and  interoperability  testing  being 
developed  and  performed  by  the  University  of  New  Hampshire  and  the  European 
Telecommunications  Standards  Institute  (ETSI).  The  testing  has  been  assigned  to  one 
agency,  but  that  testing  could  be  expanded  to  include  other  agencies  and  subordinate 
commands.  The  testing  should  remain  centralized  under  DISA  to  ensure  that  DoD  IPv6 
fielding  is  coordinated,  does  not  duplicate  efforts,  and  does  not  introduce  interoperability 
or  assurance  risks.  There  should  be  testing  by  other  organizations  under  the  lead  of  DISA 
and  it  should  be  more  aggressive. 

6.  Additional  Human  Resources  Must  Be  Dedicated  to  the 
Standards. 

The  research  effort  can  only  be  sustained  if  the  DoD  builds  a  base  of  skilled 
human  resources.  The  specific  research  focus  areas  should  include  interoperability, 
security,  and  transition  mechanisms.  The  DoD  should  support  the  development  of  new 
applications  and  initiate  test  beds  in  addition  to  Moonv6. 
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F.  POTENTIAL  FUTURE  RESEARCH  QUESTIONS 

For  networks  that  have  not  transitioned  to  IPv6,  how  has  the  maintenanee  of  the 
IPv4  network  affected  security?  How  has  it  affected  the  budget?  How  has  it  affected  the 
acquisition  of  IPv4  capable  equipment? 

Has  the  DoD’s  push  to  make  the  transition  to  IPv6  helped  or  hindered  the  market? 
Have  shortcuts  been  taken  to  in  order  to  meet  the  equipment  and  services  demands  of  the 
DoD?  How  involved  is  the  DoD  with  getting  IPv6  information  to  its  users, 
administrators,  and  school  houses? 

How  has  IPv6  affected  mobile  communications?  Is  there  an  architecture  in  place 
that  allows  IPv6  to  be  used  by  the  operating  forces  on  the  move?  Does  IPv6  equipment 
pass  conformance  tests? 

Are  the  Milestone  Objectives  on  schedule?  If  not,  what  can  be  done  to  get  them 
back  on  track?  Do  the  live  packets  on  the  GIG  meet  the  intended  criteria?  What  security 
risks  surfaced  after  the  live  packets  hit  the  GIG? 

What  is  the  status  of  IPv6  applications  and  service  support?  What  guidance  has 
been  released  since  the  transition  plan  of  2005? 

What  equipment  has  been  conformance  tested  for  security?  What  percentage  of 
the  tested  equipment  meets  the  security  criteria  set  by  NS  A?  Has  NS  A  approved 
encryption  devices  that  satisfy  the  intelligence  community  at  large? 
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APPENDIX  A:  AGENCY  IPV6  INVENTORY  GUIDANCE 


This  appendix  contains  the  format  used  to  collect  an  inventory  on  existing 
devices.  The  agencies  were  directed  to  conduct  an  inventory  of  existing  IP-aware 
switches,  routers,  and  hardware  firewalls.  The  inventory  was  to  be  conducted  per 
“investment”  as  defined  in  0MB  Circular  A-1 1,  section  53.  The  first  inventory  had  to  be 
reported  to  0MB  no  later  than  November  15,  2005. 

Agencies  also  had  to  provide  a  second  inventory  of  all  IP  compliant  devices  and 
technologies  not  captured  by  the  first  inventory.  Agencies  were  directed  to  provide  a 
progress  report  as  part  of  their  February  2006  Enterprise  Architecture  (EA)  submission  to 
0MB.  This  inventory  must  be  completed  and  reported  to  0MB  no  later  than  June  30, 
2006. 

Both  inventories  were  to  include  the  data  elements  found  in  Table  1,  below,  for 
each  device/technology: 


IPv6  Transition  Checklist 

1.  Investment  (Name) 

Investment  Name: 

InvestmentBYOe  UPl: 

Agency: 

Sub-Agency: 

Program  Manager: 

Phone: 

Email: 

Prime  Support  Contractor: 

2.  Investment  Information 

a.  Investment  Description: 

Number  of  Distinct  Types  of 

Appllcatlons/Devices: 

Percent  of 

Appllcatlons/Devices  IPv6 
Compliant: 

Number  of  Distributed  Sites 
Associated  with  this  Investment 

3.  Identify  Applications  or  Devices  used  within  this  Investment:  (Add  more  lines  as  required,  see  Type  Code  legend 
below)  -  Additional  details  are  required  for  complete  Inventory  at  the  bottom  of  this  report. 

Appllcatlon/Device  Name  (Acronym) 

Purpose  Type 

Manufacturer/Vendor  Name 
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Type  Code  Legend: 

G  =  Government  Off-the-Shelf  C  =  Commercial  Off-the-Shelf  MC  =  COTS  Modified  by  Government  Contract  but  still 

S  =  Shareware  F  =  Freeware  available  to  the  public 

RT  =  Router  Device  FD  =  Firewall  Device  SW  =  Switch  Device 

AD  =  Authentication  Device  OD  =  Other  Device  VD  =  VPN/Remote  Access  Device  available  to  the  public. 

HD  =  Host  Device  CD  =  Client  Device  . 


4.  Identify  Applications  or  Devices  that  are  not  IPv6  compliant 


Application/Device  Name  (Acronym) 

Describe  dependence  on 

Impact  (see 

IPv6  Compliant 

IPv4 

Legend) 

Date 

Impact  Code  Legend: 

Legacy  =  App/Device  will  be  replaced  before  2008  and  will  not  transition.  Mod  =  Will  be  modified  by  date  identified 
Upgrade  =  New  IPv6  compliant  version  will  be  implemented  by  date  identified  Waiver  =  Waiver  will  be  submitted  per 
guidance  in  Transition  Plan 


5.  Identify  reliance  on  IPv4: 

a.  Define  how  IPv4  is  implemented  preventing  IPv6  capability:  (Database  fields;  hard-coded  addressing;  proprietary 
protocol  implementation;  IPv4  loopback  addresses;  reliance  on  non-IPv6  OS,  COTS,  or  GOTS) 

b.  Identify  the  amount  of  IPv4  address  space  used  by  the  investment  in  terms  of  approximate  CIDR  address  blocks,  e.g. 
/20,  /24,  etc. 

6.  Technical  impact  of  transition  to  IPv6; 

a.  Describe  what  needs  to  be  done  to  achieve  initial  dual  stack  capability  and/or  full  transition  to  IPv6. 

b.  Describe  IPv6  characteristics  that  will  or  should  be  leveraged  as  part  of  the  system’s  architecture  (i.e.  stacked 
headers,  site/link  local  addressing,  mobile  IPv6,  IPSec,  unicast/multicast/anycast,  stateless  autoconfiguration). 

7.  Dependencies: 

a.  Describe  technical  dependencies  that  will  impact  the  IPv6  implementation,  i.e.  processor  or  memory  constraints,  APIs, 
etc. 

b.  Describe  loaistical  dependencies  external  to  vour  svstem,  i.e.  interrelated  oroarams  (C2PC,  TDN,  etc.)  Uooer  Laver 
Protocols  and  aoblications. 

8.  Programmatic  impact{s): 

a.  Schedule  for  systems  to  be  dual-stack  and  full  IPv6  compliant  using  current  Development  Schedule.  Include 
deployment,  fielding,  upgrade,  and  retrofit  milestones. 

(1)  Cost  schedule  -  list  currently  budgeted,  such  as  for  tech  refresh  or  upgrade,  and  additional  funding  required 
(deficiency)  for  each  FY  to  achieve  initial  and  objective  IPv6  capabilities  in  8a.  EXAMPLE:  FY07  $20K($5K),  FY08 
$8K($0) 

b.  Accelerated  schedule  for  systems  to  be  dual-stack  and  full  IPv6  compliant  if  current  Development  Schedule  does  not 
meet  the  goal  of  IPv6  compliant  by  2008.  Include  deployment,  fielding,  upgrade,  and  retrofit  milestones. 

(1)  Cost  schedule  -  list  currently  budgeted,  such  as  for  tech  refresh  or  upgrade,  and  additional  funding  required 
(deficiency)  for  each  FY  to  achieve  initial  and  objective  IPv6  capabilities  in  8b.  EXAMPLE:  FY07  $20K($5K),  FY08 
$8K($0) 

9.  Define  technical  and  programmatic  risks. 

10.  Define  Risk  Mitigation  Strategy  for  items  identified  in  block  9. 

1 1 .  Can  this  investment  or  the  systems  in  the  investment  become  a  representative  "early  adopter”?  (Yes  /  No) 

12.  Recommendations:  (Enter  any  comments  or  ideas  you  have  that  have  a  bearing  on  this  initiative) 
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Application  and  Device  Inventory 


(Additional  details  continued  from  question  #3  above) 


Application/Device 
Name  (Acronym) 

Version 

/OS 

Device  iD/ 

Seriai  number 

Cost 

(OOOs) 

Device  Capabilities 
(iPv4,iPv6,  duai 
stack) 

For  Firewali  Devices:  Does 
Device  have  the  abiiity  to 
monitor  tunneled  IPv6  traffic 
(Type  41  Packets)  and 
conduct  Deep  Packet 
Inspection  (Yes  /  No) 

Supported 

Standards 

Manufactur 
er  Upgrade 
Plan 

Technical 

Refresh 

Date 

Device  Security 
Level/Criticality 

Known  Issues  with 
Device 

Table  2. 


Agency  IPv6  Inventory  Guidance  (From:  OMB,  2005) 
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APPENDIX  B:  IMPACT  ANALYSIS 


This  appendix  contains  a  description  of  the  impact  analysis  that  was  to  be 
completed  by  November  15,  2005.  The  agencies  were  to  provide  progress  as  part  of  the 
February  2006  agency  EA  submission  to  0MB.  The  results  of  this  impact  analysis  are  to 
be  reported  to  0MB  no  later  than  June  30,  2006  and  must  include  both  cost  and  risk 
elements  as  described  in  0MB  Circular  A-1 1 . 

Cost  estimate  should  include: 

1 .  Planning 

2.  Infrastructure  Acquisition  (above  and  beyond  normal  expenditures) 

3.  Training 

4.  Risk  mitigation  cost 

Risk  Analysis  should  consider: 

1 .  Schedule 

2.  Technical  obsolescence 

3.  Feasibility 

4.  Reliability  of  systems 

5.  Dependencies  and  interoperability  issues 

6.  Surety  (asset  protection)  considerations 

7.  Risk  of  creating  a  monopoly  for  future  procurements 

8.  Capability  of  agency  to  manage  the  investment 

9.  Overall  risk  of  investment  failure 

10.  Organizational  and  change  management 

1 1 .  Business 

12.  Data/info 

13.  Technology 

14.  Strategic 

15.  Security 

16.  Privacy 

17.  Project  resources 

18.  Human  capital 
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APPENDIX  C:  TRANSITION  ACTIVITIES  NOTIONAL  SUMMARY 


This  appendix  contains  guidance  for  the  CIO  Council  so  that  it  could  develop 
additional  transition  guidance.  The  agencies  were  directed  to  address  the  actions  as  soon 
as  possible.  Beginning  February  2006,  agencies’  transition  activity  was  to  be  evaluated 
using  0MB ’s  Enterprise  Architecture  Assessment  Framework: 

1 .  Conduct  a  requirements  analysis  to  identify  current  scope  of  IPv6  within  an 
agency,  current  challenges  using  IPv4,  and  target  requirements. 

2.  Develop  a  sequencing  plan  for  IPv6  implementation,  integrated  with  your 

agency  Enterprise  Architecture. 

3.  Develop  IPv6-related  policies  and  enforcement  mechanisms. 

4.  Develop  training  material  for  stakeholders. 

5.  Develop  and  implement  a  test  plan  for  IPv6  compatibility/interoperability. 

6.  Deploy  IPv6  using  a  phased  approach. 

7.  Maintain  and  monitor  networks. 

8.  Update  IPv6  requirements  and  target  architecture  on  an  ongoing  basis. 
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